I can't see any problem its only encoding time.
Its illogical thinking that higher quality slower algorithms are worse
I don't really subscribe to this idea of "it's whatever you find to be transparent, if you can't tell the difference between lower and higher bitrates and quality settings, then the higher bitrates and quality settings are not better".
What if I'm playing music to one of my friends and they can tell the difference?
I'm not bothered about file size and encoding time
People might now scream at me "well that's obviously -b 320 -q0" but not if q0 is buggy, experimental and untested.
I fail to see what has actually been changed by you introducing a hypothetical third party into the equation.
Peteharrison, sounds like you would prefer using a lossless codec.
People have said "Its illogical thinking that higher quality slower algorithms are worse" and "I cannot see why q0 would not provide higher quality in some cases. Its more analysis and with cbr/abr that's a good thing" but is q0 buggy?I'm not bothered about file size or encoding time, I just want to use the settings that have the highest chance of providing transparency all the time.I don't really subscribe to this idea of "it's whatever you find to be transparent, if you can't tell the difference between lower and higher bitrates and quality settings, then the higher bitrates and quality settings are not better". What if I'm playing music to one of my friends and they can tell the difference?Again, I'm not bothered about file size and encoding time, I just want to use the settings that provide the best quality that Lame is able to offer. People might now scream at me "well that's obviously -b 320 -q0" but not if q0 is buggy, experimental and untested.I just want the best quality Lame is able to provide.
For the highest quality I'd use -V0 or halb27's variant . VBR may have the edge on preecho these days even against -b320. I advise against b320 unless you have some vbr compatibility issue as its not gonna solve certain cases. If you can use something other than mp3 go for mpc Q6 / 7 or vorbis Q7. These will give 200..230k vbr with better efficiency than mp3 320k
If you ask me (which no one did ) I would like to see how low of of bit-rate I can get away with without noticing lossy artifacts. With LAME, I would use -V5 or -V3. Once I depended on a portable player that did not implement VBR correctly I said to hell with CBR MP3 at 192/256/320kbps and moved on to AAC. It is not a major issue for me since I have the lossless source material.
I found this thread interesting.I have been using -b 320 -q 0 recently because:1) In the past LAME MP3 has not always been transparent to me even using preset extreme, so I use whatever the highest setting is regardless of if an improvement over relatively lower bit rates has been proven or not.So far this setting is transparent to me so that is pretty darn cool. IIRC the last time I ABX'd a CBR 320 file was with an significantly older version of LAME.
That means difficult-to-encode sections actually will exceed 320kbps while easier sections will take less space.
q0 might increase the theoretical quality, of something that is already transparent, so providing no audible benefit.
VBR does not use -q0. It uses a different process so it would find no use of what -q0 does.
e:\>lame -V0 --verbose bla-bla.wavLAME 3.99.5 32bits (http://lame.sf.net)CPU features: MMX (ASM used), SSE (ASM used), SSE2polyphase lowpass filter disabledEncoding bla-bla.wav to bla-bla.mp3Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=0)
Finally, the quote about 320kbps is partially true. The format has a limited set of frame sizes, which, when added up to one second of audio, represent the different bitrates. Changing the frame size from one frame to another is what ABR and VBR do, but there is also one thing called "bit reservoir".Bit reservoir is a mechanism in which unused bits of the previous frame can be used as bits for the next frame. So two consecutive "320kbps" frames could actually be "220kbps" and "420kbps". (I put quotes because the actual frame size is way less than that).With VBR, this is not as much needed as in CBR, because packets can adapt easily, but that's why conceptually, one could have more data in one precise moment than the limit of the frame.Probably this explanation is more in favour of CBR, but bit reservoir is quite more strict than what VBR can do when choosing different frame sizes.
My encoder disagrees:(q=0)
I'm afraid I don't get your point fully. Do you claim that VBR is better for having up to 420kbps for difficult parts? Doesn't CBR use constant bitrate and constant frame size?