Can anyone give a definitive answer on whether using -q0 with -b 320 will provide better quality than using -b 320 without a -q switch, when encoding with the latest version of Lame (3.99.5)? I've read various posts about it and some say it's buggy, some say it's in an experimental stage of development and some say it's brilliant. If -q0 isn't recommended, can better quality be achieved when using -b 320 with another -q switch as opposed to using -b 320 without a -q switch?
Thanks.
You need to check out halb27's constraint vbr variant (http://www.hydrogenaudio.org/forums/index.php?showtopic=103431&st=0&p=850346&#entry850346) if you want to improve on cbr 320.
Without double-blind test results for the specific tracks you want to encode, there is no point in commenting about sound quality for various encodes.
And my understanding is that the default is -q3, which is mapped to the same thing as -q0.
...or just use VBR and never mind the -q switch.
And my understanding is that the default is -q3, which is mapped to the same thing as -q0.
AFAIR, this applies to VBR only, with the two being different under CBR. Interested readers can check this for themselves in the source code or, if not feeling that adventurous, perhaps in previous discussions on this same old question.
And my understanding is that the default is -q3, which is mapped to the same thing as -q0.
Yeah I was just about to say I thought that's only in VBR. I just encoded a track using -b 320 without a -q switch so the default of q3 was used (as was illustrated in the Lame encoder window) and then I encoded the same track using -b 320 with the -q0 switch and the encode with the -q0 switch took 4 times longer, 28 seconds instead of 7, so in CBR q3 isn't mapped to q0.
If -q0 isn't recommended, can better quality be achieved when using -b 320 with another -q switch as opposed to using -b 320 without a -q switch?
As a
broad generalization - If you are getting audible artifacts at 320kbps (or V0), there's probably nothing you can do to improve the default performance.
Just wanted to point out that -h (which means high quality on the documentation) is mapped to -q 2.
Just wanted to point out that -h (which means high quality on the documentation) is mapped to -q 2.
Yeah it's strange that the developers have set the 'high quality' option to map to -q2 and not -q0, which is presumably higher quality although when I read the documentation it did say "-q 2: recommended. Same as -h. -q 0 and -q 1 are slow and may not produce significantly higher quality.". I kinda thought nothing of it but I assume the difference between q2 and q0 really must be either negligible or nothing at all, or else why would the 'high quality' setting (-h) be q2 and not q0? It's still kinda counter intuitive if you want the highest quality to not use the highest quality setting (q0) and to use q2 instead... Unless the numbers are arbitrary and q2 is the best quality, due to q0 being buggy or experimental, if it is, or maybe it's just because q0 and q1 are slow and they are better quality than q2 but only by a negligible amount.
I would simply add that most if not all of the tuning of the algorithms was probably performed with -h, so use of any other switch means using relatively untested areas of code. That's enough for me to stick with -h.
First, about the OP's question: There is no definitive answer, because it hasn't been tested extensively.
Now, onto LAME's history:
The lame -q switches have had several evolutions during their history, including when they didn't exist and there was just -f and -h.
They are mostly related to CBR, because for VBR, the process of encoding is less dependant on how hard it tries to fit the data into the specified bitrate.
I won't enter much in detail, but the lame changelog has some information related to what was added to the different options.
Said that, it's important to understand this:
-f (and the -q 9 to -q 6 options) disable some of the analysis tools related to psychoacoustics and quantization. This means it calculates less information and as such, can make mistakes easier. The goal in this case is exclusively speed.
-h (and the -q 3 to -q 0 options) enable extra loops and analysis that allow to find the best compromise out of several options. The goal in this case, was to increase the quality for a determined bitrate. (CBR, remember?).
Now, onto the -q0 bug, the -q3 is the new -q2, and the -h is mapped to -q2 thing:
Several years ago, -q0 had a bug in its algorithm that could (i.e. not always) cause worse quality than -h (-q2 at that time). The bug was in the inner loop that tries to get the best quality by "brute force". Later on, this was fixed, but again it didn't receive much testing.
Later, a new "brute force" algorithm was created, and was activated with the -q 0 setting. This meant than then, all qualities were moved one position up. I.e. old -q2 became -q3, old -q0 became -q1 and so on (and yes.. old -q9 disappeared).
What didn't get changed was the quality to what -h was mapping, so this is why now -q 3 is the default (which used to be -h), and -h maintains the old mapping, that was -q 2.
It didn't help that nowadays, LAME is mostly tested for VBR, and as has been said already, the quality values work differently for VBR because they don't activate the same things.
I would simply add that most if not all of the tuning of the algorithms was probably performed with -h, so use of any other switch means using relatively untested areas of code. That's enough for me to stick with -h.
I wonder why there isn't any mention of the -h switch (or the -q switches) on the wiki recommended settings. It says for best quality use -b 320 (with no switches). I wonder if it is safest to use -b 320 with no switches because that way you're using the developer's default settings that are regarded as safe / stable so there is the lowest likelihood of getting any artifacts. Can anyone clarify that? Is that the thinking behind -b 320 without any switches being listed in the wiki recommended settings?
I wonder why there isn't any mention of the -h switch (or the -q switches) on the wiki recommended settings. It says for best quality use -b 320 (with no switches).
That's because -h is the default, so there is no need to include it.
That's because -h is the default, so there is no need to include it.
-h isn't the default. When you use -b 320 with no switches it defaults to q3 and when you use -b 320 -h it maps to q2. I know q3 is the old q2 but in the Lame documentation and when you run lame --longhelp it says -h is the same as -q2 and it's recommended to use -h. If that is the case, on the wiki why doesn't it say it's recommended to use -h? Perhaps the Lame documentation is out of date and things have changed.
Probably because there no evidence that it provides any improvement in general.
Please refer to my first post in this discussion:
http://www.hydrogenaudio.org/forums/index....st&p=850498 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=103451&view=findpost&p=850498)
It isn't just my opinion; it is forum policy (http://www.hydrogenaudio.org/forums/index.php?showtopic=3974).
The nice thing about using the default in this case, is that you got the same results from one version to the next, even when the definitions of -q and -h were changing.
I distrust any switch for which the response to the question "What does it do?" is "For which version?"
One of a few very good reasons why we do not recommend additional switches.
Most of the information we have on the q switch is here:
http://wiki.hydrogenaudio.org/index.php?title=LAME_-q_switch (http://wiki.hydrogenaudio.org/index.php?title=LAME_-q_switch)
The information is based on previous discussions, feedback from the developers, the various documentations, verbose output of the lame tools, and the file headers of the resulting files.
EDIT: Note that those descriptions are as set by the LAME devs on the various docs, not Hydrogen Audio.
Can anyone give a definitive answer on whether using -q0 with -b 320 will provide better quality than using -b 320 without a -q switch, when encoding with the latest version of Lame (3.99.5)? I've read various posts about it and some say it's buggy, some say it's in an experimental stage of development and some say it's brilliant. If -q0 isn't recommended, can better quality be achieved when using -b 320 with another -q switch as opposed to using -b 320 without a -q switch?
Thanks.
Will it provide better quality, YES.
Ask yourself this... If you pour a 1000 gallons of water into the ocean. does it increase it's level... YES. But would someone on the other side of the world notice the change?
Can you hear the difference... I can't answer that, but I think probably not.
It doesn't hurt for archiving but is the encoding time worth it? On my machine -b320 encodes at 38x where as -b320 -q0 does 10x
With lossy encoding, sound quality depends on what you can prove. If you cannot tell the difference between a -q0 encode and a -q3 encode then -q0 is not any better.
I suppose interested parties could try mushra testing files encoded to 112 CBR with various -q values in order to possibly get a sense of how the setting works, though once you hit transparency, there really is no such thing as increased quality.
Will it provide better quality, YES.
Ask yourself this... If you pour a 1000 gallons of water into the ocean. does it increase it's level... YES. But would someone on the other side of the world notice the change?
That example is illustrative, but it is not completely correct, because increasing the level of quality does not mean "add more quality". It strictly means use more tools to determine the best usage of bits to retain the level of quality that the tools can analyze.
Between q3 and q0, there is also a change of some parameters, as described by the wiki article posted by Makaki, that change the level required. But that does not necessarily mean more quality, it means what is allowable.
As for the scenario described by greynol, testing a lower bitrate has its pros and cons. Since the bitrate is more restricted, trying harder can obtain a better representation of bits than what a lower q would do, but also, since less bitrate is available, the increased level of some parameters might not be fullfilled.
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. If we deviate in the other direction - towards Q9 thing do degrade at a certain point. Obviously Q3 was chosen as a 'sweet spot' for speed vs quality just like compression levels vs speed in lossless coders. To me it seems most people are after very fast encoding which I can understand and it becomes easy to dismiss the slower settings on those grounds that they are mostly 'useless'.
Whether the differences are audible is another issue. But if one isn't in a big hurry I'd give -Q0 or -Q1 a go using a lower encoding priority .
It doesn't hurt for archiving...
Oh yes, it does hurt just using a lossy codec for archiving, whatever the codec and the bitrate or the quality level. It is a practice not to be endorsed.
Is it me, or are the arguments presented to support the idea that lower q values result in higher quality are just circular reasoning?
Whether the differences are audible is another issue.
No, whether the differences are audible is
the issue.
mostly useless
Show me an example where it is useful @320 (per the topic) and you will have a leg to stand on.
I can't see any problem its only encoding time. Its illogical thinking that higher quality slower algorithms are worse - I think on some samples there will be improvements . In my next round of testing I'll compare default q3 cbr to -q1 / 0 on some problem samples and report back.
Until you or someone else tests the proposition, talking about how you think one thing and expect another is not going to get anyone anywhere.
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.
I can't see any problem its only encoding time.
Are you sure about that? Others talking about the actual code seem to tell a different story.
Its illogical thinking that higher quality slower algorithms are worse
Basing hard conclusions on gross oversimplifications is more logical?
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".
Fair enough. But most other members here do.
What if I'm playing music to one of my friends and they can tell the difference?
Then what matters is whatever
they find to be transparent; if
they cannot tell the difference between lower and higher bitrates and quality settings, then the higher bitrates and quality settings are not better. Or
they can evaluate whether -q0 is better in the newest version of LAME using systematic blind testing as suggested earlier. I fail to see what has actually been changed by you introducing a hypothetical third party into the equation.
What if I'm playing music to one of my friends and they can tell the difference?
Then your friend is in a unique position to do more than just speculate as to how many angels actually
are dancing on the head of that pin.
Since we're entertaining hypotheticals, what if your friend found that certain passages sounded better with one setting while others sounded better with a different setting?
I'm not bothered about file size and encoding time
I wouldn't be either if bigger and slower actually gave such assurances.
FWIW, I'm pretty sure the forum has seen examples where VBR made an improvement over 320 CBR.
People might now scream at me "well that's obviously -b 320 -q0" but not if q0 is buggy, experimental and untested.
I hate to break it to you but don't be surprised to find out that none of the q settings have actually been tested.
I fail to see what has actually been changed by you introducing a hypothetical third party into the equation.
What I should have said was I don't 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" because I don't care if even I can't tell the difference between the settings, I just want the piece of mind of knowing that I am getting the best quality that is possible with Lame, with the least chance of getting any artifacts (using whatever settings would achieve that, not necessarily q0).
Yet again: Define how something can be higher quality than transparent. And how will you know that this trend will hold for all possible input samples? Sorry, but the sort of conclusive answer you want is very unlikely to exist in reality.
And again: Answering the question with any degree of usefulness would require, at a minimum, systematic double-blind testing of LAME 3.99.5 with various input samples and output settings. I am not aware of anyone having done so. Thus, it seems, we continue to speculate about vague suspicions that remain unverified.
Peteharrison, sounds like you would prefer using a lossless codec.
Peteharrison, sounds like you would prefer using a lossless codec.
There are some situations where users might desire the highest possible quality out of LAME, regardless of file size or how long the process takes. And an example of that could be a car stereo, or a home stereo that supports MP3 but does not support lossless formats.
Consider the following:
1) The user "wants" lossless but the device doesn't support it.
2) The user is worried that what he may find transparent, another person might find artifacts. A probability that is increased the more people are added to the equation. Thus the concept of adding a cushion or safety margin by selecting a higher bitrate. (or higher quality settings)
3) The goal is to pick encoding settings that would satisfy the audio perception of the highest amount of people possible. Without considering file size or compression time, because those people will not be able to see the file size and will not be able to tell how much time it took. They would just be listening.
So the question sums up to: Is there a point that regardless of file size and time, there is a reverse effect on quality. That can be asked of the bit rate chosen and the algorithm path chosen.
Out of a large test group, is it safe to say that the higher the bit-rate, the larger the percentage of people that will find the encoding transparent. And that the statement holds true for the entirety of the bit rate scale, without exceptions.
Now the same question should be asked for the Q settings. For a large test group, is it safe to say that the lower the Q value, the larger the percentage of people that will find the encoding transparent? And does the statement hold true for each possible value of q, without exceptions. If not, for which values of Q does the statement not hold true.
Note that diminishing returns is not factored into this perspective. It may very well be that FOR EXAMPLE the percentage of people that find (-b 320) transparent is 99% and that lowering Q value changes it to 99.000001%, but you are still gaining something. I would be worried if the percentage would reverse itself (eg: 98%)
I Know that the correct answer would require extensive blind-testing by a large population. Just wanted to give me interpretation of the question.
Well stated.
It isn't as if this is a unique question. It has been asked here many many times over, just ask skip252.
There is no extensive testing and there likely will never be any. The example isn't real and IMO the expectation it poses is unreasonable.
Regarding listening in a car, whatever the real numbers are in the "example" given, they will change depending on the listening environment, hardware and source material. It bares repeating that the "best" settings can change as well.
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
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
Hmmm but the wiki seems to suggest that -b 320 might have the edge over V0 as it says "-b 320 is an alternative to the VBR settings above.
This CBR mode will maximize the MP3's bitrate and overall file size. The extra space may allow for some parts of the audio to be compressed with fewer sacrifices, but to date, no one has produced ABX test results demonstrating that perceived quality is ever better than the highest VBR profiles described above."
Yeah, it says no one has produced ABX results to demonstrate -b 320 is better but it does seem to suggest that -b 320 could have the edge over V0
You really should stop looking for absolutes where none exist.
@peteharrison86 I think you should check on the documentations about VBR encoding. Even Lossless Compression uses VBR algorithm.
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.
In the current discussion, it seems to me the opposite is happening: the OP appears to want transcodes that are future-proof. This is not realistic. Even if one were to examine and identify the ultimate -q setting, there is a better/more precise/transparent successor to follow within a couple years time (thanks to users like HA's founders and many users including halb27).
I can not imagine any tangible shortcomings of -b 320 despite the warm-fuzzy feeling of using slower settings. As long as the original source files are available, one can simply re-encode those affected albums/tracks at -q0/etc and feel reassured.
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.
As a casual user, I would tend to agree with this. Before I knew any better I started "archiving" my CD collection using MP3s, then after learning the error of my ways switched to FLAC. -V4 or so is fine for me nowadays.
It's simply impossible to find the "best" i.e. "most universally transparent" settings in LAME. The amount of empirical evidence that would have to be amassed - in finding enough listeners, enough hardware sets, enough environmental conditions, and enough audio samples to adequately answer the question - approaches infinity. That's why the experienced users on this board are urging that you focus on what is transparent for YOU, or common co-listeners, alone.
That said, as others have stated it's generally accepted in LAME that
(1) at high bitrates, VBR typically exceeds CBR or ABR in transparency. This is because extra bits can be reserved for difficult-to-encode sections such as sharp attacks or those that would cause preechoes.
(2) halb27's variant seems to address many problematic samples better than LAME 3.99.5. That said, LAME 3.100a2 also seems to do so. Combining the two may be even better but I think the jury's still out on that one.
(3) There is a LOT of discussion on what to do about the upper frequencies. Some insist that they need to be encoded accurately; others insist on a severe lowpass filter, and many (such as myself) end up in somewhere in between.
(4) the settings most likely to produce transparency in compliant MP3s** may be along the lines of
-V0 --cvbr 0 -Y --lowpass -1 in halb27's 3.100m variant. But be warned that this is a relatively untested variant of an alpha build.
(5) Note I didn't include -q0. It is implicit in -V0 --cvbr 0.
**In my opinion ONLY, of course, and with no empirical evidence to back it up. Per point 3, a lot of people would take issue at the -Y or --lowpass -1 switches.
Wow, I think this is the third popular topic I've killed this week. Either that, or I'm just slow to respond.
Would be interested in other thoughts on points (3) through (5) above.
3 and 4 are not on-topic.
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.
2) Unfortunately FLAC does not work on everything as previously stated.
3) This setting still only takes up a fraction of the size of lossless, so I can fit more songs on my old 16 GB Cowon DAP for example. I do not not know why people always assume "archiving" just because it is a high bit rate.
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.
I might post some hopefully successful listening tests of somewhat lower bit rates if I find the time to do them, but most of the members of this forum have a scary attitude so I hesitate to do so.
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.
Greynol is correct, we're getting off-topic here. Perhaps a spin-off to discuss "LAME settings most likely to be universally transparent" is in order.
That said, if you are truly looking for "whatever the highest setting is regardless...", I'd highly recommend you try the settings I suggested 3 posts above with halb27's 3.100m LAME variant. The bitrate would still be close to 320 (around 318 in my tests) yet LAME makes better use of the available space. That means difficult-to-encode sections actually will
exceed 320kbps while easier sections will take less space. This is opposed to the -b 320 behavior which gives every section 320kbps regardless of difficulty - meaning difficult sections don't get enough, and easy sections get too much.
That means difficult-to-encode sections actually will exceed 320kbps while easier sections will take less space.
Are you sure about this? For all I know, standard mp3 format is unable to handle frames above 320kbps maximum bitrate.
I think -q0 doesn't do any harm. It's definitely much slower but on modern PCs it'n not a big deal especially one doesn't encode bunch of discographies. Maybe it doesn't give plus audible quality but maybe it does. So -b320 -q0 provide the theoretically highest possible mp3 quality, higher than V0 (which automatically uses q0 setting).
@Roscoe: This thread precisely wants to avoid making the statements you've made.
In lossy codecs, the theory does not always translate to reality. We agree that q0 can offer (as in possibility of) higher quality, due to an increase of quality thresholds versus q3, and due to an extra loop that checks different scenarios to choose the best one.
What is said is :
q0 by itself does not necessarily mean higher quality, because it might choose the same data than q3.
q0 is not as much tested as q3, so there is the possibility (although there is no proof of this for the current version) that decides incorrectly.
q0 might increase the theoretical quality, of something that is already transparent, so providing no audible benefit.
Even if it might sound counterintuitive, q0 is better suited for low bitrates rather than high bitrates, because then every tiny bit counts more.
VBR does not use -q0. It uses a different process so it would find no use of what -q0 does.
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.
q0 might increase the theoretical quality, of something that is already transparent, so providing no audible benefit.
I agree. That's what I said too.
VBR does not use -q0. It uses a different process so it would find no use of what -q0 does.
My encoder disagrees:
e:\>lame -V0 --verbose bla-bla.wav
LAME 3.99.5 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
polyphase lowpass filter disabled
Encoding bla-bla.wav to bla-bla.mp3
Encoding 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.
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?
My encoder disagrees:
(q=0)
I was going to change that a couple of days ago, because I have always had the impression that it is confusing. That "q" means the value indicated to -V, i.e. -V1 will show q=1, -V2 will show q=2 and so on.
If you use the --vbr-old switch (or a LAME version previous to 3.97), you will see that then, it shows VBR(q=x) qual=y , where y is the -q setting.
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?
That's what I was trying to explain. The frame size is fixed, but part of the bits inside frame A can be used for a frame B that comes after A.
VBR is able to use bit reservoir as well, and does it, but generally it needs much less reservoir because it can adapt the frame sizes.
My encoder disagrees:
Did you take the time to read the thread and follow the links that were given before posting?
Specifically, you should have seen this:
http://www.hydrogenaudio.org/forums/index....st&p=850682 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=103451&view=findpost&p=850682)
Did you take the time to read the thread and follow the links that were given before posting?
Yes, I did.
I've read your comment but we are of different opinion. You say it doesn't worth improving quality beyond transparency, I say it actually does. That is why many people use lossless formats, or ogg and aac with average bitrates above 320kbps.
I've also read the -q document (http://wiki.hydrogenaudio.org/index.php?title=LAME_-q_switch) linked earlier and it's a little bit unclear, it's inadequate to settle the question of this topic. In my opinion LAME developers should write a lot more detailed documentation than this (http://lame.cvs.sourceforge.net/viewvc/lame/lame/USAGE) to bust every myths and prevent topics like this.
(...)You say it doesn't worth improving quality beyond transparency, I say it actually does. That is why many people use lossless formats, or ogg and aac with average bitrates above 320kbps.
Congratulations! That's by far the most literal definition of
placebo effect I've ever seen.
(...)In my opinion LAME developers should write a lot more detailed documentation than this (http://lame.cvs.sourceforge.net/viewvc/lame/lame/USAGE) to bust every myths and prevent topics like this.
Shouldn't we, first of all, be
thanking Lame developers (and for that matter most other format's) for a great piece of software that's been adequately serving us non golden-eared mortals for more than a decade, before starting to slag them off?
I never said (nor would I ever say) it isn't worth improving quality beyond transparency because that would imply that I believed such a phenomenon exists.
With lossy encoders you cannot improve sound quality beyond the point of transparency by any objective means. To argue that this is opinion misses the point of perceptual encoding. Divining "better than transparent sound quality" as the reason for using lossless or overkill settings doesn't change the landscape. Even if it is the reason many people do what they do, it doesn't mean they are right or even justified in doing so.
Regarding the q switch as it relates to VBR vs. CBR, if you do a little more research you will find they use different algorithms. As such, there is no point in equating a specific q value in one to that in the other.
I apologize for throwing that link out like I did since it doesn't address the point I thought it was going to address. I am the one guilty of not reading thoroughly enough.
Congratulations! That's by far the most literal definition of placebo effect I've ever seen.
This is not black or white. If it were, record companies would provide only mp3 discs and lossless audio and placebo formats would become extinct. What about editing and transcoding?
Shouldn't we, first of all, be thanking Lame developers (and for that matter most other format's) for a great piece of software that's been adequately serving us non golden-eared mortals for more than a decade, before starting to slag them off?
Yes, we should be and actually we are, but objectively more detailed documents are still needed. I didn't intend to slag them off or something like that.
transcoding
Transcoding mp3 has been fairly well documented as being a very bad idea.
Regardless (and assuming this is still on-topic), saying that q0 improves sound quality when transcoding requires objective evidence. Do you have any?
This is not black or white.
I'm sorry you've lost me here.
If it were, record companies would provide only mp3 discs and lossless audio and placebo formats would become extinct.
Since transparency
does not apply to lossless encoding whatsoever, why bringing that up? To compare oranges and apples!?
What about editing and transcoding?
Eew! Editing what? Lossy files!? That's definitely a no-no!! And again, if you by any rate, meant lossless encoding, please refer to my reply above.
Transcoding mp3 has been fairly well documented as being a very bad idea.
I know.
Regardless (and assuming this is still on-topic), saying that q0 improves sound quality when transcoding requires objective evidence. Do you have any?
I didn't claim q0 does inevitably improve transcoding. I'm just saying inaudible quality improvement could be useful in general, for example in the case of transcoding. There are situations when you have to transcode mp3, for example you don't have the original source still you are providing low bitrate mp3 stream from lossy source having higher bitrate.
I'm just saying inaudible quality improvement could be useful in general
"Could be useful in general" doesn't cut it in a discussion that was created for the sole purpose of obtaining a definitive answer. Furthermore (and again!), there is no such thing as inaudible quality improvement. Improvement necessarily implies audible difference, which requires objective evidence in the way of double-blind test results.
There are situations when you have to transcode mp3, for example you don't have the original source still you are providing low bitrate mp3 stream from lossy source having higher bitrate.
You have the lossless source to create a bloated mp3 and then you don't? Please explain why this is a worthwhile scenario.
If you know of any professional service that archives to 320kbit mp3 or employs other such stupid practices, please share so that we know what to avoid.
Did some tests recently using 3.99.5 on this sample:
http://www.hydrogenaudio.org/forums/index....mp;#entry853181 (http://www.hydrogenaudio.org/forums/index.php?showtopic=103898&pid=853181&st=0&#entry853181)
File sizes are the same:
1 200 586 bytes / -b320
1 200 586 bytes / -b320 -q0
But after using mp3packer (without the -z):
1 199 024 bytes / -b320
1 198 463 bytes / -b320 -q0
File with -q0 seems to be smaller here, probably because a better psychoacoustic model removes more information. It is completely the opposite of "inaudible quality improvement" since -q option is to increase perceived quality only, and will not reduce mathematical difference.
I'm not sure how to make out the opposite of what is an imaginary concept.
Did you perform a double-blind test and determine the difference was audible?
Is anyone able to ask the developers if q0 is still in an experimental stage of development or if it is now stable / 'safe'?
using q0 will create some error in playback? the only reason why q0 is not suggested is that is not tested too much?
This thread is not for general questions about -q. The last 2 questions are off-topic.
A quick answer for both of them: if the developers decide the code path enabled by -q 0 is something they want to recommend, they will make it the default.
This thread is not for general questions about -q. The last 2 questions are off-topic.
A quick answer for both of them: if the developers decide the code path enabled by -q 0 is something they want to recommend, they will make it the default.
this will mean that -q0 will be as default in the next realease? i remember many discussion about the fact that is no much tested and the inner loop problem that could not chose the right quality
Well if it is true that there's not much testing, inner loop problem, etc., what do you think the answer is?
This thread is not for general questions about -q. The last 2 questions are off-topic.
A quick answer for both of them: if the developers decide the code path enabled by -q 0 is something they want to recommend, they will make it the default.
this will mean that -q0 will be as default in the next realease? i remember many discussion about the fact that is no much tested and the inner loop problem that could not chose the right quality
but you said that developers decide to set -q0 as default and reccomended it
Well if it is true that there's not much testing, inner loop problem, etc., what do you think the answer is?
but you said that developers decide to set -q0 as default and reccomended it
@webpower: I assume English is not your native language, as you failed to get the correct meaning of the sentence.
if _something_is_true_ then that_thing_happens
You read " they will do it". You didn't read "If the developers decide".
And about this thread: It simply tried to say from the beginning, that -"q0" is not "necessarily better" than, for example q2. This, and only this. The different posts try to explain why.
@webpower: I assume English is not your native language, as you failed to get the correct meaning of the sentence.
if _something_is_true_ then that_thing_happens
You read " they will do it". You didn't read "If the developers decide".
And about this thread: It simply tried to say from the beginning, that -"q0" is not "necessarily better" than, for example q2. This, and only this. The different posts try to explain why.
yes, you're right, english is not my native speaking language, but passing throught this fact: can you please explain to me or give me a link to something that explains clarefully why -q0 "should not" be the best possibility and is better to use -q3? and what about q1? you just said "is not necessarily better" this means that could be worse?
i tried to read some other post, the most clarifying anwser i've red is that "q0 did not received much testing to be considered as the best quality value" somewhere else I also red that maybe developers considered to set is as a default behaviour in the next release of LAME.
those are contraddicting answers. why should not use q0? because could produce a worse output? or only because at least it could be the same quality as q3? and - I repeat - what about the middle range values? like q1 and q2? looks like that inner loop algorithm affects only q0, theorically q1 and q2 should be avoiding this problem. PS: i don't care about the encoding process time to spend.
Thank you.
Naturally, we might be able to measure, for a given piece of audio, some objective differences with the different -q settings. Maybe one always has slightly less of a certain type of noise. But if the noise is masked or is just so minor that no one can judge the quality as better through blind testing, then the quality is by definition the same! In other words, in order for a quality difference to exist, it must be audible. This was one of greynol's last points in this thread.
If you are talking about -b 320 like the original poster, then IMHO it's quite unlikely that your choice of -q will make any difference. The files will sound the same to everyone.
-q0 is noticeably slower than -q3, but not necessarily better. IMHO that's also the reason why -q0 is not default.
a question about i would like to get an answer is about q1 and q2, i heard that q0 is not good because is not much tested and because it uses inner loop algorithm that should get the best compression but is not guaranteed. So, is better to use q3. and what about q1 and q2? they don't use inner loop algorithm, why they are not reccomendend the same?
a question about i would like to get an answer is about q1 and q2, i heard that q0 is not good because is not much tested and because it uses inner loop algorithm that should get the best compression but is not guaranteed. So, is better to use q3. and what about q1 and q2? they don't use inner loop algorithm, why they are not reccomendend the same?
Probably because they are slower and less well tested.