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: LAME 3.97 strings not working in EAC (Read 3401 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME 3.97 strings not working in EAC

Howdy all - a questions that I kinda hope is dumb (e.g., easily solved!)

I have been using EAC 0.95b3 with LAME 3.96.1 for quite some time with very good results using the --preset standard settings. So I decided to try LAME 3.97b1.

Config: User Defined Encoder
LAME settings: %s %h --preset standard

Works just fine. So then I thought I would try the new faster VBR algorithm and changed the string to:

-V 2 --new-vbr

Trouble is, no matter what combinations I try - leave out the <--new-vbr>, whatever - I get error messages each time to try to encode. No detail is given, just "The external compressor returned an error!"

When I try using the SAME STRING to encode a WAV file via command line, LAME works just fine.

I have read over the HA posts about 3.97 strings and I seem to be following the rules. What gives? Any ideas? How is EAC altering the string when it passes the parameters?

LAME 3.97 strings not working in EAC

Reply #1 –
Never mind - figured it out. EAC still requires the %s %h parameters, so the total string is:

%s %h -V 2 --vbr-new

I admit I don't understand why the %s and %h parameters need to be there, and why they employ a '%' prefix instead of a '-'. But it's working now.

Any light shed is still appreciated.

LAME 3.97 strings not working in EAC

Reply #2 –
%s and %h are placeholders for input- and output- file. The reason for the "%" instead of "-" is simple: these placeholders aren't "sent" to the lame encoder. Instead, EAC changes them with the actual filenames of the files to be encoded when starting the encoder. So they have in fact nothing to do with the encoder parameters.

The lame encoder should have shown an error that these aren't specified when you left them out...

LAME 3.97 strings not working in EAC

Reply #3 –
Quote
%s and %h are placeholders for input- and output- file. The reason for the "%" instead of "-" is simple: these placeholders aren't "sent" to the lame encoder. Instead, EAC changes them with the actual filenames of the files to be encoded when starting the encoder. So they have in fact nothing to do with the encoder parameters.

The lame encoder should have shown an error that these aren't specified when you left them out...
[a href="index.php?act=findpost&pid=339306"][{POST_SNAPBACK}][/a]


OK, now I have a question - where can I find documentation on the EAC specific placeholders? I know the ones that control file naming (they are presented directly by EAC in the dialog) but when it comes to compression-related setting it seems that all my searches find is innuendo and partial information.

This would be really useful - thanks for any help.

LAME 3.97 strings not working in EAC

Reply #4 –
Never mind again! I just found what I needed buried in the FAQ.txt document that ships with EAC.

This illustrates why we use tech writers at my company - to keep everything where it is easily found and indexed. Oh, well - got what I needed.

LAME 3.97 strings not working in EAC

Reply #6 –
BradPDX: that's not %s and %h, but %s and %d.

%s and %d are source and destination. %hs are used to wrap around the string that is sent to the encoder when the High Quality radio button is selected.  A five minute research (FAQ, Wiki or even Google) would have told you that.

start78: nice link, it should be incorporated into the FAQ.
 

LAME 3.97 strings not working in EAC

Reply #7 –
Had my doubts about the "h", but thougth that it has to be right, since it works for him. Should have looked in my EAC settings!