Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: different output between lame on windows and linux (Read 13111 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

different output between lame on windows and linux

hi guys, I'm new on this forum, I'm going to explain my problem:

I encoded some wav file with lame.exe 3.99.5 32 bit on windows with this CLI: "-b 320 -q 0 --noreplaygain -m s"
then i've made the same thing on lame, same version on linux debian.

both the output files should be identical, but not, if i compare them with "diff" i state that they are different, but with the same size. Why this issue? who is wrong?


another last question: if "-q 0" it's slower, butt better quality, why the default behaviour is -q 2 ?

thank you, bye

different output between lame on windows and linux

Reply #1
You need to compare the actual decoded PCM, just diffing the file won't work because the headers won't necessarily be the same.

That said, there are differences between compilers and sometimes even CPUs, so the output may or may not be identical depending on how the binaries are encoded and run.

different output between lame on windows and linux

Reply #2
both the output files should be identical
Who said that? It is untrue. Different compilers and/or CPUs performing floating-point arithmetic are perfectly likely to produce minor differences in the output of those mathematics, and programmers will tolerate those differences in contexts such as lossy encoding where absolute identity is not a criterion. Those differences are highly unlikely to be perceptually significant.

Quote
Why this issue? who is wrong?
The only wrong thing is the common misconception that all binaries of a given lossy encoder will produce identical output, although to be fair, it is not a particularly intuitive concept, so your previous assumption was understandable.

Quote
another last question: if "-q 0" it's slower, butt better quality
Normally I would request that you start another thread for an unrelated question like this, but we have enough on the subject already. Some help file or guide somewhere might claim that -q0 offers higher quality, but it is not necessarily true in anything other than a theoretical and unproven way. Systematic generalised double-blind testing on material representative of an average collection is the only valid way to judge this, and I am not aware of anyone having done that work.

Quote
why the default behaviour is -q 2 ?
-q3 now, and of course, the reason that it is the default is that the developers decided to make it the default. Perhaps they too thought -q0 was a solely theoretical benefit that had not been proven useful enough to spend the additional CPU clocks that it would incur.

Any other questions you have about -q have probably been addressed multiple times in previous threads; please search for those.

different output between lame on windows and linux

Reply #3
ok, so, it's better to get lame linux output or lame windows output?

PS. both the executable are on the same PC, so on the same CPU

i think also that floating point differences can be solved setting manually FPU values, you don't think so?

different output between lame on windows and linux

Reply #4
ok, so, it's better to get lame linux output or lame windows output?


Doesn't matter. One is not better than the other, they are just slightly different. It is like asking "does a picture look better when viewed on a linux or windows computer?".

different output between lame on windows and linux

Reply #5
ok, so, it's better to get lame linux output or lame windows output?


Doesn't matter. One is not better than the other, they are just slightly different. It is like asking "does a picture look better when viewed on a linux or windows computer?".


yes, maybe should be better on linux because LAME was released mainly for linux OS, and windows version is only a port.

Quote from: db1989 link=msg=0 date=
-q3 now, and of course, the reason that it is the default is that the developers decided to make it the default. Perhaps they too thought -q0 was a solely theoretical benefit that had not been proven useful enough to spend the additional CPU clocks that it would incur.

Any other questions you have about -q have probably been addressed multiple times in previous threads; please search for those.


lame help saids this:

-q <arg>        <arg> = 0...9.  Default  -q 5
                    -q 0:  Highest quality, very slow
                    -q 9:  Poor quality, but fast
    -h              Same as -q 2.  Recommended.

so, default is -q 5 and not -q 3, and reccomended is -q 2. right?
and what thiference there is between "default" and "reccomended" ?

different output between lame on windows and linux

Reply #6
yes, maybe should be better on linux because LAME was released mainly for linux OS, and windows version is only a port.

No, LAME is a multi-platform encoder.

so, default is -q 5 and not -q 3, and reccomended is -q 2. right?

No. LAME built-in help text is outdated and inaccurate.

different output between lame on windows and linux

Reply #7
Quote from: lvqcl link=msg=0 date=
No. LAME built-in help text is outdated and inaccurate.


I'm reading also from here: http://lame.cvs.sourceforge.net/viewvc/lame/lame/USAGE

but looks like the same as built in lame longhelp

"-h  use some quality improvements.  The same as -q 2."

different output between lame on windows and linux

Reply #8
Repeating the same points does not make them any less outdated.
(A) -q3 is the default, not -q5
(B) -h is not specifically recommended, at least not by the majority of this community, which has become the de facto authority on usage of LAME

Reading a better-maintained piece of documentation would have proved these: http://lame.cvs.sourceforge.net/viewvc/lam...detailed.html#q As would the previous threads that I already recommended earlier.

different output between lame on windows and linux

Reply #9
Latest useless thread on -b320 -q0:
http://www.hydrogenaudio.org/forums/index....howtopic=103451

Spoiler alert (as if useless wasn't enough):  there is no evidence only speculation and hand-waving.

different output between lame on windows and linux

Reply #10
ok, in the end:

1) encoding on windows or on linux makes no differences, is irrelevant, and there is not one better, right?

2) i need to get all the quality, and i don't care about the encoding speed, in this case is always better to use -q 0. right?

thank you


different output between lame on windows and linux

Reply #12
2. WRONG!  It doesn't seem like you were paying attention to what was said on this part.


on the other thread somebody told:

Quote from: [JAZ] link=msg=0 date=


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.


so, if that bug have been fixed, why shouldn't be the better algorithm?

different output between lame on windows and linux

Reply #13
I take it you read our Terms of Service that was presented to you upon registration and you did the requisite research before posting.

With that in mind, how do we judge sound quality?

different output between lame on windows and linux

Reply #14
I take it you read our Terms of Service that was presented to you upon registration and you did the requisite research before posting.

With that in mind, how do we judge sound quality?


yes, i've searched and i've red all this thread "http://www.hydrogenaudio.org/forums/index.php?showtopic=103451&st=0"
but not understanding why, if a new algorithm substituing the old -q0 and now the old -q0 was mapped as -q1, you continue to reccomend to use -q3 instead of -q0. the buggy algorithm at this time is -q1. On the other thread there is not an answer to this. I'm not asking to judge sound quality, i'm asking what are the correct parameter to get the best sound quality

so, summarizing al that i've learned in this forum is that:

1) reccomended parameter to get the best sound quality is -q3.
2) -q3 on the last version corresponds on -q2 on the older version
3) if I do use -q2 on the last version, i'm using -q1 of the past version
4) -h mapping has not been refreshed and still continue to refeer to -q2 that now is the old -q1.

what does I care to understand is why the last -q0 algorithm is not reccomended.

Thank you

different output between lame on windows and linux

Reply #15
what does I care to understand is why the last -q0 algorithm is not reccomended.


Presumably because:

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.

different output between lame on windows and linux

Reply #16
I'm not asking to judge sound quality
Of course you are.

By requisite research, I meant our rules and pinned topics, specifically as they relate to how one determines best sound quality.  Such research would have led you to this post:
http://www.hydrogenaudio.org/forums/index....st&p=149481
Prior to that you would have come across the following sentence:
"Graphs, non-blind listening tests, waveform difference comparisons, and so on, are not acceptable means of providing support."
"and so on" includes anecdotal claims and unsupported interpretations/gross generalizations of settings and third-party descriptions of those settings (e.g.: bigger and slower must mean better, gold is shinier than silver).

In the case of lossy compression, best is transparent (you cannot distinguish the lossy version from the original).  There is no "best" once lossy test subjects are at that point; they are all the same.  When test subjects are not transparent there are objective ways of determining a preference.  Reading setting descriptions and anecdotal claims are not objective ways.  Relying on objective data presented by someone else doesn't exactly qualify either.

I would like to think this forum makes recommendations based on evidence that is in accordance with our governing principles.  I also believe some respect be paid to authority (read: developers and other established credible sources who follow proper scientific protocol) and established data in the event that one cannot otherwise support a definitive answer.  The day when this forum accepts less is the day that I will stop contributing, not that I expect you to care.

My old signature would have ended my posts better in this topic.  It went along the lines of, "all things sound the same unless proven otherwise."

EDIT: Regarding my saying that other topic was useless, I meant the quest for "a definitive answer".  I do not find factual contributions such as that provided by [JAZ] useless.

different output between lame on windows and linux

Reply #17
what does I care to understand is why the last -q0 algorithm is not reccomended.


Presumably because:

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.



no, read it better.


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).


is the actual -q1 that was fixed without much testing, then was introduced a new one.

different output between lame on windows and linux

Reply #18
...which somehow was tested to ensure it could and would produce objectively noticeable improvement and only improvement?

Keep dreaming.

different output between lame on windows and linux

Reply #19
...which somehow was tested to ensure it could and would produce objectively noticeable improvement and only improvement?

Keep dreaming.


yes, you are right, but it could also produce something with worse quality than -q3 ?

 

different output between lame on windows and linux

Reply #20
Speculation doesn't provide any answers.

Show me an example of where there is a demonstrable difference in either direction.  Evidence speaks volumes.

different output between lame on windows and linux

Reply #21
ok, but if you think it in this way, you shouldn't say not even that q3, q4 are better than q7, q8. you should simply say, I do not know which one is better, use whatever you want and be fun.

different output between lame on windows and linux

Reply #22
Most people consider that the developers assigned a default value, assume that they had a sensible reason for doing so and can be trusted, and hence use the default value.

different output between lame on windows and linux

Reply #23
I have always been a proponent of determining what works best by testing and in the event you encounter an odd sample that exhibits audible artifacts which you find unacceptable, try something else for that sample.

Regarding the slippery slope over q values, increasing the q value can do things like disable the psychoacoustic model, so no, it doesn't make sense to use settings (extreme or otherwise) that produce audible results you deem unsatisfactory.

And, yes, have fun experimenting!

different output between lame on windows and linux

Reply #24
my mistake was born on the fact that I stated different values in "dbpoweramp" frontend for windows that uses LAME as the encoder,

here you can see 3 voices: "Slow (High Quality), Normal, and Fast (Low Quality)"

the first corresponds to -q2 , the second to -q3 and the last to -q7.

the strange thing is that if i do use -q3, from the application, it produces a different output file than using lame from the command line using the same CLI



somebody of you know why?