Support and General Use > Audio Playback, Database and Playlists

What are the best behaved audio file formats for RockBox?

<< < (2/3) > >>

gonzalexx:
Excellent!!!
Thank you guys...
There's some playing to be done then.  I haven't used decoders deliberately before... of course, by deliberately I mean aware of the difference they make in playback, since that's the magic of your standard players... they make everything seem transparent and seamless to the listener... a file will sounds pretty much the same... but when I noticed the different behavior from rockbox with my old ipod... I started to wonder.
In fact, before rockbox was in my box, the old battery would last very little, but it was predictable... then I went on vacation to Alaska, and in the cold.... well... it would not last at all... then... back home in the tropics, it was back to its predictable behavior until I loaded rockbox, and started noticing very significant differences in battery usage... so I did order a nice battery replacement, so I can see the behavior as it should be seen... it was about time too.
Now I have more reasons to mind file formats, and decoders.
Thanks for the eye openning experience!!!

Zardoz:
Hi gonzalexx
I'm no expert, neither am I a developer but I'll add my two-cents nonetheless.
I've always favoured .ogg or .mpc. I'd recommend musepack I think - it seems to introduce less 'artifacts' and decodes pretty smoothly across all Rockbox targets. It's a naturally or native variable-bit-rate codec so it optimizes the compression as well as can be expected (--quality 4 works well for me.) I guess it's one of the least well supported codecs 'out there' so if you plan to move files to commercial players using original firmwares it's, maybe, not a good choice (except for most Cowon players.)
The less compression/encoding done the less decompression/decoding needed so I guess it goes without saying that a lossless codec (.flac, .ape etc) is slightly better in terms of processor load than a lossy one. But as cool_walking and Llorean said, the file will be bigger and take longer to read/buffer.
Codec performance seems to vary (pretty dramatically) across targets. I use an ipod 5.5g 80GB, for my sins and .mpc or .mp3 works best for me in real-speak.
Sorry for the long, non-committal reply!!
keep the faith
z

soap:

--- Quote from: Zardoz on September 19, 2008, 09:12:53 PM ---The less compression/encoding done the less decompression/decoding needed so I guess it goes without saying that a lossless codec (.flac, .ape etc) is slightly better in terms of processor load than a lossy one.
--- End quote ---
Not true in two ways:
1:
FLAC was designed to be asymmetric and decode easily.
Whereas:
APE is the MOST processor intensive of the codecs.*
2:
Lossless codecs are not "less compressed" than lossy codecs, they are differently compressed.  Think of a lossy codec not as a more powerful lossless codec, but as a lossless codec which also takes into account what the human ear can actually discern, and throws away data that:
A - It knows you can't hear.
(and when asked to lower bitrate more, data:)
B - You will be less likely to notice is missing.


*Ok ok ok, APE at the compression level most people use it at is the slowest codec. 

Zardoz:

--- Quote from: soap on September 19, 2008, 09:46:29 PM ---FLAC was designed to be asymmetric and decode easily.
Whereas:
APE is the MOST processor intensive of the codecs.

--- End quote ---

OK I stand corrected  ;)

I understand how codecs 'discard' the least necessary information. It's how they determine the necessity or not that distinguishes them?

Like I said I'm no expert. My (limited) sense of logic said if a thing didn't need to be squished too much, then another thing didn't need to un-squish it too much, and all that un-squishing is done by the processor in the (rockbxed)player. The less un-squishing the better, n'est pas?

AlexP:

--- Quote from: Zardoz on September 19, 2008, 10:58:26 PM ---Like I said I'm no expert. My (limited) sense of logic said if a thing didn't need to be squished too much, then another thing didn't need to un-squish it too much, and all that un-squishing is done by the processor in the (rockbxed)player. The less un-squishing the better, n'est pas?

--- End quote ---

That doesn't follow at all.

It all depends on the algorithms used to do the compressing/uncompressing.  A codec could use a horrendously inefficient algorithm that is both computationally very expensive but still doesn't compress well.

Navigation

[0] Message Index

[#] Next page

[*] Previous page