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: EAC & LAME 3.96 --ps problem (Read 4197 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC & LAME 3.96 --ps problem

I just encoded some songs using EAC and LAME 3.96. When I used EncSpot to view the LAME Header I encountered a problem with the Quality Tag. As I said, I used LAME 3.96 + --preset standard, so the Quality-Tag should be set to '77', but EAC put '78' in there. I used Cdex and + LAME 3.96 + --preset standard and it did it right...I wonder why EAC is doing that? Is this value hard-coded or something? As far as I know --aps used to store Quality as '78', but that changed with LAME 3.95 I think...
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

EAC & LAME 3.96 --ps problem

Reply #1
I would think from these symptoms that you are using "Lame MP3 Encoder" instead of "User Defined Encoder" and that you have High Quality selected.

In this scenario EAC puts -h on the command line before the --preset standard that you have specified.  (It also puts a -b value based on the bitrate selected but that is overriden by the preset, so is irrelevant here).

-h maps onto -q2 whereas the default is -q3.  In 3.90.3 it seems that this -h switch is ignored as it is overriden by the subsequent preset, but in 3.96 it seems to be taken into account.  However, from the couple of files I have tested it appears there is no difference between the actual audio data generated by 3.96 --preset standard with -q2 and -q3.  I am not sure why this would be the case, but at least it means there is nothing much to worry about except that the different quality value is written into the Lame Tag.

The solution is to use User Defined Encoder instead of Lame MP3 Encoder.  User Defined  Encoder gives you full control over the exact command line that is used, without EAC adding to it behind the scenes.


EAC & LAME 3.96 --ps problem

Reply #3
@ phwip

thanks for your explaination  So, I don't have to re-rip my files...because technically I got an even better quality since -q2 instead of -q3 was used, right?

thanks
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

EAC & LAME 3.96 --ps problem

Reply #4
I wouldn't re-rip.

From my tests I would say the audio data is identical, not "better quality", but that's all you need.

I am interested to know why with 3.96 --preset standard there is no difference in the audio data between -q2 and -q3.  The other -q values seem to make a difference.  -q1 and -q4 create quite different files.  Perhaps somebody with more of an understanding of how 3.96 uses the -q values can explain this?

EAC & LAME 3.96 --ps problem

Reply #5
ok, I don't seem to get EAC to work that it uses --preset standard (without adding any other switches). If I select "User Defined Encoder" it just rips the *.wav file and right after that is done it says that encoding is finished (but no file has been created).

Also, in the first TAB it shows me a list of many encoders (including LAME 3.96). I selected --preset standard (Sample Format). However, when I want to encode to mp3, it just rips the file as *.wav 
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

EAC & LAME 3.96 --ps problem

Reply #6
if you use User Defined Encoder instead of Lame MP3 Encoder then you need to add %s %d to the end of the command line after --preset standard.  EAC substitutes these with the name of the wav file to encode and the name of the MP3 file it should encode to.  Otherwise you are executing lame but not telling it which file to encode.

(On an aside, with Lame MP3 Encoder selected, EAC automatically appends the wav and mp3 filenames to the command line which is why you have not needed the %s %d before).

Ignore everything on the first tab (Waveform).  If you have selected "Use external program for compression" on the second tab then all the boxes on the first tab are ignored by EAC and should all be greyed out anyway.

EAC & LAME 3.96 --ps problem

Reply #7
Select "User Defined Encoder" and enter "--preset-standard %s %d" as the "Additional command line options".

%s stands for "source filename", and %d stands for "destination filename"

Take a look at this page, about three quarters of the way down. "Which flags can I use in the external compression scheme "User Defined MP3 Encoder"?"

edit: meh, too slow.

EAC & LAME 3.96 --ps problem

Reply #8
ok, thanks to both of you  However, I wonder what 'Waveform' stands for...as I said, LAME 3.96 shows up there...is it just to get an overview of all the settings available?

Edit:
now it worked! However, why does Cdex produce a slightly higher file than EAC does? No ID3 Tags were written, the Bitrate distribution is the same (according to EncSpot) and both files have the same amount of frames 
--alt-presets are there for a reason! These other switches DO NOT work better than it, trust me on this.
LAME + Joint Stereo doesn't destroy 'Stereo'

EAC & LAME 3.96 --ps problem

Reply #9
I think, although I'm getting into areas I have not really looked into now, that the Waveform tab is for if you are using a dll to encode within the EAC process, rather than an external .exe encoder.

As for Cdex, I have never use it, but I can vouch for the fact that ripping and encoding with EAC gives identical files to if you ripped with EAC to wav and then separately encoded using lame.exe on the command line.  Perhaps it is something to do the ripping stage rather than encoding, such as whether gaps are being appended to the track or not?