The SD library code is large but its RAM requirement is also large and I presume that that is what you are really running into. As Jimmy60 has pointed out, one way to get around it is to put just the SD part in another Arduino. Another way would be to replace the SD in the original sketch with an I2C EEPROM and store the data in a raw form. Then write a separate sketch which extracts that data in its verbose form as and when required. You'd just have to figure out what size of EEPROM you would need to hold sufficient data so that the data extraction doesn't have to be performed too often.
I'm getting old and cynical but I do not believe for one nanosecond that the vast majority of these people are at "uni". There is simply no way that someone could get to their "final year project at uni" and be so clueless about electronics and/or programming unless they are majoring in stupidity and sloth. Most of these so-called "final projects" (some even have the gall to call it a thesis) are also so fundamentally trivial that I cannot believe, for that same nanosecond, that any self-respecting "uni" would accept the project as worthwhile and worthy of what are presented as being degree granting institutions. Occams' Razor strongly suggests to me that these threads are initiated by spotty 14-year olds who are just trolling and having "fun".
You have declared to be local to the loop function so every time you enter loop() the count variable is created anew and initialized to one. You should declare it to be global (outside loop) so that it won't be regenerated all the time.
That code claims to start Timer1 interrupting every microsecond and then has an ISR routine that: - can't possibly execute in less than a microsecond - calls Serial.print (as PaulS has pointed out) - calls delayMicroseconds(15) inside a loop that is executed a minimum of 36000 times and (if that's not enough silliness) it also calls delayMicroseconds(2) in a loop that executes a minimum of 270000 times. It therefore can't possibly be sampling the audio at a consistent rate which would permit it to detect an audio tone (even if the code's detection method could actually work in the first place).
Don't use the String library. The Arduino does not have enough ram (only 2kB) to do anything other than trivial things with Strings. You will have to convert your code to use character string arrays (C-style null-terminated strings).
I have the 32-bit one. IMHO it isn't really useful for a 16MHz Arduino. IIRC the FPU is based on a processor whose clock is only twice as fast as the Arduino and it doesn't have floating point hardware. The thing that kills it is the amount of time required to send your data to the FPU and then get the results back. If you want to offload some computations while the Arduino does something else it might be useful. Before you buy one read the instruction timings in the data sheet, figure out how much data you have to shovel in and out and decided whether it will save you any time. [addendum] I should mention that it has several features that I haven't used. For example the NMEA sentence parser and 2 12-bit A/D converters Pete
The code could be modified to handle six inputs but it would slow down the sampling rate quite substantially which would change the characteristics of the detection. A better way to handle the audio sampling is to use a timer interrupt and do the detection on-the-fly but in either case you would probably need a faster processor to handle six channels.