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 13235 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

different output between lame on windows and linux

Reply #25 –
Different in what way? Through a naive diff as in the original post? And where does it cite the differences as being? dBPA might write different tags of its own or something else like that, as saratoga already indicated about the headers. Check with a proper audio-based comparator, at least.

different output between lame on windows and linux

Reply #26 –
Quote from: db1989 on
Different in what way? Through a naive diff as in the original post? And where does it cite the differences as being? dBPA might write different tags of its own or something else like that, as saratoga already indicated about the headers. Check with a proper audio-based comparator, at least.


no, I just removed tags with a tag editor, both the files are without ID3 tags,



as you can see, what dbpoweramp is to encode the input file using lame.exe giving that paramteres.

then if i give directly the same parameter and input file throught command line terminal, it produces a different file.
No idea why, it's quite strange.

different output between lame on windows and linux

Reply #27 –
And yet again I ask what you used to perform the comparison, which differences it reported, and where. The difference could be a single bit from having flagged the MP3 as original in your screenshot (this is just an example; I do not know what that flag really represents or its default value) or anything as minor as that. Without you telling us what these differences are, there is no point speculating about them emptily.

different output between lame on windows and linux

Reply #28 –
no, if i deselect "original", it will add the -o option in the CLI. the strange thing is that if i use "slow (high quality)", it comes with -q 2, and so, if i also use -q 2 with command line, in this case both the output will be identical, for -q3, this is not true.

here it is a windiff sreenshot between the two different output about -q3


now let me check the debug information...

different output between lame on windows and linux

Reply #29 –
ok, solved the problem, one last question: do you think that dbpoweramp is wrong when it maps "slow(high quality)" to -q 2 ?

different output between lame on windows and linux

Reply #30 –
Quote from: webpower on
ok, solved the problem, one last question: do you think that dbpoweramp is wrong when it maps "slow(high quality)" to -q 2 ?


I could be wrong, but I thought in VBR mode there is little difference between q 3 and q< 3, so thats probably ok.  For CBR, yes I would probably say thats not a great idea.  You generally don't want to stray too far from the recommended settings or else you risk running into less well tuned bits of the code. 

In practice I have no idea how much it matters.  You'd have to test and see.

different output between lame on windows and linux

Reply #31 –
Quote from: webpower on
ok, solved the problem
What was the difference? And you solved it by doing what? I doubt many of us want to try to guess from those screenshots.

Quote
one last question: do you think that dbpoweramp is wrong when it maps "slow(high quality)" to -q 2 ?
This is all about semantics and what different people class as right or wrong in that sense. dBPA probably talks about high quality when it means -h, which does indeed map to -q2, in which case, it is correct in that particular sense. Whether or not the quality is actually higher on average in a perceptual sense is, again, an unknown that must be tested widely before anyone can claim much about it.

Quote from: saratoga on
I could be wrong, but I thought in VBR mode there is little difference between q 3 and q< 3
Again: http://lame.cvs.sourceforge.net/viewvc/lam...detailed.html#q
Quote
For the default VBR mode [--vbr-new] since LAME 3.98, the following table applies
-q 0 to -q 4   Use the best algorithm.
-q 5 to -q 9   Use the not so good algorithm

different output between lame on windows and linux

Reply #32 –
Not the first post illustrating (no pun intended) the problem with Lame GUIs putting the q value front and center when it should be buried under advanced options. In the case of VBR it should be overhauled at the very least; if not removed entirely(!), since changing it away from the default will likely only provide undesirable results in the event that differences are noticeable.  I shouldn't pick on just 3rd-party implementations when the suggested GUI also exhibits the same flaw.

Does anyone care to address the decision to force stereo frames?  I would but I have gotten so calloused about it that my response will surely come off as insensitive and condescending. Yes, I'm fully aware that was passive-aggressive.

Seriously though, it makes zero sense to expect the encoder to milk every bit to its fullest potential while prohibiting it from using a lossless transform in order to achieve greater precision with those very same precious bits.

different output between lame on windows and linux

Reply #33 –
Quote from: db1989 on
Again: http://lame.cvs.sourceforge.net/viewvc/lam...detailed.html#q
Quote
For the default VBR mode [--vbr-new] since LAME 3.98, the following table applies
-q 0 to -q 4   Use the best algorithm.
-q 5 to -q 9   Use the not so good algorithm



Mmmm... Looks like I'll have to update that, according to the current knowledge in the wiki: LAME Q Switch

And I'll definitely take a look at modifying the old .txt files that cause so much confusions. (Might try to update the man pages too, if i can build and check that I don't break them).

different output between lame on windows and linux

Reply #34 –
Quote from: db1989 on
Quote from: webpower on
ok, solved the problem
What was the difference? And you solved it by doing what? I doubt many of us want to try to guess from those screenshots.

sorry but it was my fault, in command line I was not adding "-m s", so, it produced a different output

about dbpoweramp, why -h continues to be mapped to -q2?, as it was remapped to -q3, why -h has not been updated?

different output between lame on windows and linux

Reply #35 –
I think it's pretty useless to have a decision on -q values because there's nobody around who has real useful answers.
That's why people usually stick with the default -q value. As long as nobody has a sample where say -q 0 has a real benefit this is supposed to be the most adequate way of handling this question.
As for dbpoweramp it's a pity that they are producing unnecessary complexity and confusion by having settings for -q value, stereo mode, and more weird stuff on their GUI, especially as they are providing a way of adding any special option the user likes.
lame3995o -Q1.7 --lowpass 17

different output between lame on windows and linux

Reply #36 –
quote from LAME help: "    -h              Same as -q 2.  Recommended." is -q3 that now is reccomended, why LAME continues to reccomend -q2? what is the difference between default and reccomended?
 

different output between lame on windows and linux

Reply #37 –
Is there a reason why you refuse to believe that documentation may lag project development?

different output between lame on windows and linux

Reply #38 –
Quote from: tpijag on
Is there a reason why you refuse to believe that documentation may lag project development?


no, -h corresponds to -q2 also when you execute it, and not only on the documentation

maybe there will be a different between "reccomended" and "default", no field equals to "default", -h equals to "reccomended"

different output between lame on windows and linux

Reply #39 –
Long story short:
-h is an alias. This alias was once mapped to -q 2. At some point, q 2 became q 3, but the alias was not updated.
Also originally the default for LAME was -q 5 and later on, the default was changed to -q 3, which was the supposedly "recommended" setting.
(Note: I've avoided mentioning when there was no -q setting)

So now there is:
- Not up-to-date documentation (The Html help has been up-to-date for several years, but the text files and man pages, and even some of the --longhelp info has not been properly updated).
- Setting (-h) that once meant one thing, but now it is just another q value.
For all that we know, the -h setting could be changed to mean -q 0 nowadays, and maybe (if the documentation is changed accordingly) stop discussing if -h is recommended or not.


Even shorter story:
I am maintaining the documentation.  Is there anything else you think is wrong?

different output between lame on windows and linux

Reply #40 –
ok, but nowadays, (ignoring the fact that -h has not been updated to -q3) using -h is redundant because just the default q value is the same as -h, so, why don't you remove -h option? (considering the fact that -q3 is not the best quality value, but only the reccomended)

another question: reading the documentation i'm stating that of -q0 and -q1 there is an higher "AMPLIFICATION" value, it is "2". what does this rappresent?

thank you

different output between lame on windows and linux

Reply #41 –
I am only involved in the documentation. (I am a coder and I could modify the code, but I am not involved in the development).
The -h setting is widely known (to frontend programs, at least), and removing it could made them stop working (if this made them switch to the q scale, it could be positive, but I am not the one to take that decision).

As I say, nowadays it might be worth changing the alias to -q 0, but that's up to the developers to decide.

As for the meaning of q0, those are internal settings that aren't necessarily easy to explain. I am describing them in the help file as "higher precision parameters".

different output between lame on windows and linux

Reply #42 –
Quote from: [JAZ] on

I am just involved in the documentation. (I am a coder and I could modify the code, but I am not involved in the development).
The -h setting is widely known (to frontend programs, at least), and removing it could made them stop working (if this made them switch to the q scale, it could be positive, but I am not the one to take that decision).

As I say, nowadays it might be worth changing the alias to -q 0, but that's up to the developers to decide.

As for the meaning of q0, those are internal settings that aren't necessarily easy to explain. I am describing them in the help file as "higher precision parameters".



I'm noticing a lot of contradiction, in the past posts, sombody else tried to explain to me a dozen of times that there is not a valid reason to say that -q0 produces a better output, and it hasn't been tested enough. Now you say that maybe, you will set -h to -q0. I'm a little bit confused 

There is no way to know the truth?

PS: i've asked you another question:

Quote from: webpower link=msg=0 date=
another question: reading the documentation i'm stating that of -q0 and -q1 there is an higher "AMPLIFICATION" value, it is "2". what does this rappresent?

different output between lame on windows and linux

Reply #43 –
There is no contradiction between saying that -q 0 and -q 1 are not as tested as the default, (which is -q 3), and suggesting to move the (now almost useless) -h setting to -q 0, which is the highest q setting.

According to the wiki post, from q 4 to q 0 they do mostly the same things, changing slightly the values to analyze (supposedly increasing the safety margin, but it's not clear that the margin is worth it in terms of audible differences).
q 0 also enables an additional search loop, which is intended to improve the huffman encoding.  I don't know enough the algorithm to say if that can make audible improvements from q3 to q0, and more so, if we talk about high bitrates. At lower bitrates, every bit is an improvement.


Ps: when replying, do not full quote the post if it isn't necessary. Your previous post was already modified because of this.

different output between lame on windows and linux

Reply #44 –
ok, but i'd like to get an answer about "AMPLIFICATION" value about -q

different output between lame on windows and linux

Reply #46 –
I mean this in the most positive way possible, but it might be time to stop caring so much about little and, equally importantly, unconfirmed, things.