I've read with interest the various comparisons of encoders at different settings, but haven't seen much about the relative file sizes produced. I think it's important to compare formats based not on setting, but on the size of the files produced. Picking a particular lame setting because it's 'supposed' to be the same as a particular wma setting is not valid, if the wma files are twice the size as the lame ones.
So I've made a start on comparisons of settings by size, starting with ogg and wma. In the future I hope to include lame, and maybe more...
I've only just started, but as an example, ogg -q5 is nominally equivalent to wma 160kbps, but based on file size 5.11 would be more realistic.
http://audio.ciara.us/compare.htm
Cheers, Paul
Full Version: Encoding by size, not setting
This was much less of an issue in the past as most encoders were CBR (or at least something with a stable quality <==> filesize mapping), so filesize wasn't a consideration, because it was always going to be close. 128 kb/s is 128 kb/s whether it's mp3, wma, aac, or some other codec. Makes relative quality comparisons at a given bitrate much easier.
With more encoders moving to VBR with their own quality scales, it's going to get messy for a while until we get some testing methodoliges hashed out. Maybe people smarter and more forward thinking than us already have.
But putting -q5 into lame, vorbis, and mppenc are going to give radically different results.
With more encoders moving to VBR with their own quality scales, it's going to get messy for a while until we get some testing methodoliges hashed out. Maybe people smarter and more forward thinking than us already have.
But putting -q5 into lame, vorbis, and mppenc are going to give radically different results.
A solution to that "problem" could be solved by making the encoders capable of creating 2-pass encoded files... The first pass makes a log of all relevant information and the second pass selects the most appropriate bitrate for each sample/block so that the filesize matches the one you want...
The XviD MPEG-4 encoder works like that, much more simple than choosing bitrates or quality values... Although for audio it might not be very useful for anything else than making audio tracks for movies that needs a fixed filesize...
The XviD MPEG-4 encoder works like that, much more simple than choosing bitrates or quality values... Although for audio it might not be very useful for anything else than making audio tracks for movies that needs a fixed filesize...
2pass encoding would be REALLY nice
mostly for movies sound track but also ,many other places where space is an issues like with mp3/aac mobil players
mostly for movies sound track but also ,many other places where space is an issues like with mp3/aac mobil players
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.