Columns Retired Columns & Blogs |
Loudspeakers Amplification | Digital Sources Analog Sources Featured | Accessories Music |
Columns Retired Columns & Blogs |
Loudspeakers Amplification Digital Sources | Analog Sources Accessories Featured | Music Columns Retired Columns | Show Reports | Features Latest News Community | Resources Subscriptions |
Hey Bob B,
Sandisk added native FLAC Support to their Sansa Clip (currently 1,2 or 4GB) and Sansa Fuze (2,4 or 8GB - although you can add more via Micro SDHC cards) ranges back in October of last year. Although I have not heard it myself, apparently the Fuze offers decent SQ and is keenly priced (the 8GB model is currently going for about $80 online) making it look like a pretty sweet option. You can use 400MB per album as a budgetary figure for 16/44.1 at Level 5 compression so the 8GB should give you approx 20 album's worth of room to maveuver.
I believe that the Cowon D2 players (2,4,8 or 16GB) also support FLAC although they are a bit more expensive.
Cowon has a nice series of players - they accept FLAC in just about every one - they are highly regarded in Linux communities for the support of open source formats such as FLAC and Ogg Vorbis. Purportedly they sound great - the headphone amps have enough power to do well with many high quality headphones.
I do not have, but have heard good things about these flash players:
http://www.cowonamerica.com/products/cowon/s9/
http://www.cowonamerica.com/products/iaudio/7/
(They do hard drive based ones, too)
Good to sear Sandisk is going that direction, too!
(Oh and Hello!)
Bob, don't rule out Apple just on the basis of FLAC. The only reason Apple doesn't support it, as far as I can tell, is that it requires a bit more processing power to decode than Apple Lossless does, and Apple can use a cheaper processor as a result. Any modern desktop or laptop computer can convert FLAC to Apple Lossless or back in no time flat-- my computer, which literally dates from the last century, can do a CD's worth of conversions in about 5 minutes.
The iPod's real limitation, IMHO, is not the lack of FLAC, but the fact that it's limited to 48k sampling. (I think it can do 24 bit/48k, but I can't swear to it. I know that 48k is the sampling limit in the current generation players though-- I have a fair bit of stuff encoded in 16 bit 48k.)
Go to a big box store and play around with a few portable players. Choose the one that has the user interface you like, and which sounds the least awful. (Of the ones I've used, the iPod and the Zune seem to sound the best-- and both of them sound surprisingly good. Playing lossless or AIFF/WAV files, even out of the headphone jack, either of them are sufficiently good-sounding that I've abandoned the Sony portable CD player I used to keep by the bed.)
That isn't much of an issue in my opinion as id be willing to bet that noone on this forum could tell the difference between 48k and 96. the Word length is far more important.
You may well be right- while I'm very familiar with 48/16 and 96/24, I can't say I've ever heard 96/16. 48/16 sounds ever so slightly better than 44.1/16-- or did when I was 17 years old and playing around with a DAT. Something about the way high-pitched transients (cymbals, triangles, violin harmonics) are reproduced sounds more real, probably because the brick-wall filter is a bit higher. (I clearly heard the dog whistle at the end of Sgt. Pepper's this morning, but I can't say that I can hear that much higher anymore)
Lionel,
This caught my eye as to the best of my knowledge the reverse is true. ALAC, based on what we know from Dave Hammerton's reverse engineering, is computationally more complex to decode than FLAC.
Josh Coalson, the guy who wrote FLAC, made the following observations about ALAC (my bold):
Modelling the effect of 3 is quite tricky without knowing the actual algorithm Apple has used but it would minimally result in a couple of extra multiplies per sample. Based on the above, my rough estimate is that ALAC is 10-25% more compute-intensive on decode than FLAC.
I am not familiar with the PPC instruction set so I can't comment on Josh's speculation about how ALAC might have been optimized for PPC machine instructions, however given Apple's subsequent move to Intel across their lines this is probably moot.
What is your rationale for asserting that FLAC is more complex to decode?
Maybe. But regardless, it is consistent with Apple's approach to make darn near everything it does proprietary, with their own proprietary formats. Although it benefits their products in some ways (mostly regarding simplicity and uniformity), the company has a "control freak" mentality.
XLD is a great app for converting from FLAC to ALC. Converts at 40-60x play speed. it's also the best ripper I have heard.
Hey Res,
I'd concur with your assessment. The thing I don't get is that Apple usually ploughs their own furrow in the zealous belief that they've built a better mousetrap (e.g. their magsafe power connector and new proprietary monitor cable). However I can't for the life of me figure out in what way(s) ALAC is superior to FLAC. It provides inferior compression and requires more horsepower to decode. I'm a bit baffled.
So i did some digging though apple's developer connection, and found this out. The reason apple dose not support FLAC and other formats is that the hard drive based ipods had to read data into ram (32MB) to extend battery life. This data is still compressed, but the problems arise when the ram buffer is depleted and needs to be refilled. ALC has a tracking bit, clock bits, and time code system that makes the files slightly larger than FLAC. These tracking bits let the ram buffer fill and drain, then find the very next break point on the hard drive data, and load the next section into ram. Now, this also lets the ipod store the end of song one, and the beginning of song two in ram as well at the next loading point. WAV and AIFF files have these self clocking fraction points too, but FLAC and OGG do not have these systems. Oddly, with the first video iPod apple upped the ram to 64MB, but retracted to 32MB in the classic (most likely due to better batt tech). Apperently, MP3 dose not have this tracking bit system either and apple states that playing back MP3 files over 30MB in size may cause hesitation in the audio playback. This all makes sense with mp3s because under normal operation (say a consumers 128kbit mp3s) the hard drive only has to spin up every 30 minutes or so to refill the buffer, but with WAV or ALC the hard drive can only buffer in 2-4 minutes at a time. So to get the best batt performance with larger files, the bit tracking system makes sense. Flash based players don't have this problem, but I think it's tradition in architecture that has stopped apple from adding the open source codecs.
That's a real shame for Apple. The iPod Touch would have been a slam dunk for me if it supported FLAC since that is the format my entire library is in.
Fascinating insight, ajschmidt. Thanks!
Thanks schmidt - that is indeed interesting, and I had never heard that before.
My argument to Apple is that "your hardware can play it" and people want to play it. Rockbox does it darn well. I'm usually listening to FLACs at my desk, so I don't care about battery life, and all they have to do is say "FLAC and OGG playback tax the battery more."
Oh well.