I use fre:ac to convert audio files and it has some settings for MP3 export I find useful.
I can’t get Audacity to give the same results with its presets.
The settings ni fre:ac are in its config file:
0 1 192 1100 0 5 1 0 4 90 192 0 128 0 256 0 0 1 0 0 22050 0 0 0 0 0 0 0 0 0 1 -1 1Can these be translated to a command line for Audacity export?
You don’t have to run Lame inside Audacity. Lame can be installed and run as a stand-alone program with as many options as you could want.
Koz
Yes you can use LAME or other encoders at the command-line for Audacity export. See http://manual.audacityteam.org/o/man/exporting_to_an_external_program.html.
Which commands in that long list do you find especially useful?
The commands you can use with LAME that I know of are listed here http://lame.cvs.sourceforge.net/viewvc/lame/lame/USAGE.
Is ATH Absolute threshold of hearing (for exporting with “equal loudness”) and TNS “Tonal Noise Shaping”? I think those are settings fre:ac is adding on top of LAME. LAME can do Replay Gain analysis, but it does not encode with equal loudness itself.
Gale
I don’t know … that was basically the question.
However, I used Mediainfo on the MP3 files and got this for the encoder settings used by Audacity and Fre:ac respectively:
A: Encoding settings (31.3 Kbps) : -m m -V 9 -q 3 -lowpass 10 --vbr-old -b 8
F: Encoding settings (26.5 Kbps) : -m m -V 9 -q 5 -lowpass 7.2 --vbr-new -b 8
So I can use that in the export command.
I wish there was a way to add lame presets in Audacity (without recompiling the program), but it seems they are fixed.
Audacity includes dozens of the most useful Lame presets.
What preset do you want to add that is not already included (and why)?
I would rather not have to justify a preset to a committee before I can use it, just experiment myself and give it a name if I want to to re-use it.
Anyway, back to my original question:
It seems the important setting difference was --vbr-old in Audacity vs --vbr-new in fre:ac.
Since there seemed no option to choose that I thought I would have to resort to the command line.
Then I discovered that the “fast” and “standard” option in fact gives you vbr-new and vbr-old respectively.
I’d always left it at “standard” thinking it must be better than taking a short cut.
Why would "standard be the less efficient in time and space?
But it seems the opposite:
“fast” exported a file in 39 seconds at 33 kBps.
“standard” took 92 seconds and had average rate of 37.7.
So it’s “fast” from now on.
If you want to persuade a developer to invest the time and effort to develop a new feature, then you need to present a persuasive case for why they should do so.
If you want to experiment with non-standard Lame settings, then the best way to do so is to use the stand-alone command line Lame encoder and enter your options via a Terminal.
For detailed descriptions of Lame command line switches, see the documentation here: http://lame.cvs.sourceforge.net/viewvc/lame/lame/USAGE
You can also find a lot of additional information on the hydrogenaudio forums: https://www.hydrogenaud.io/forums/
Re. Fast vs Standard:
In old versions of Lame, “Standard” produced better quality while “Fast” was faster. However, many years of development have gone into improving the “Fast” algorithm and now it is just as good (or even better in some cases) quality wise as “Standard”, while still being faster. The “Standard” option has been retained as a legacy setting but is not recommended. Use “fast”.
I just want the same options with lame as are available for ffmpeg.
Including choosing and saving presets.
Since that isn’t happening, I’ll just keep saving to wave and encoding with other programs.
Re. Fast vs Standard:
In old versions of Lame, “Standard” produced better quality while “Fast” was faster. However, many years of development have gone into improving the “Fast” algorithm and now it is just as good (or even better in some cases) quality wise as “Standard”, while still being faster. The “Standard” option has been retained as a legacy setting but is not recommended. Use “fast”.
I know that. As I stated above.
Lame calls these options “vbr-new” and “vbr-old”.
Why not use those in Audacity instead of “standard” and “fast”, since “standard” isn’t the standard any more?
“Standard” pretty much implies it’s the correct choice if you don’t have a special case but in this case it’s the opposite.
Are you asking that every LAME command is exposed in the MP3 export options including for example de-emphasis and ID3v2 padding? That would probably make the dialogue too “complex” for many users.
Some of the commands you listed are not in LAME. If Audacity was to do something similar to ATH and TNS then as I understand it they would be Audacity effects.
Note that if you use Audacity’s command-line encoder (see the link I gave) the last 12 command strings entered are saved. So if you only had 10 command strings that you ever used, you have de facto presets because you can just choose the command string you want from the dropdown.
Gale
In versions older than LAME 3.98, you had to enable --preset fast to enable the vbr-new routine. That is where “fast” comes from.
Not all users are as “advanced” as you. “Old” and “new” conveys nothing to a user who does not know what they mean.
We are saying “Fast” is recommended by making it default.
Gale
I know. But it’s confusing to use that wording now, when Lame itself doesn’t…
“Standard” vs “fast” does convey an meaning, an incorrect one.
In any program, when I see a choice between “Standard” and “Fast” the implication is that “fast” will save some time at the expense of quality.
I have no idea what the default was when I first installed the program several years ago, but the very word “standard” implies that it is the default.
As I now know, this isn’t true of the Lame setting in Audacity.
If Standard has no advantage of either quality or time, why offer it at all?
If you do, use the current Lame description “VBR-old” which doesn’t imply that it is preferred.
http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/detailed.html#vbr-old
And the answer to my question?
Or is what really matters to you that you can set your own combination of options as a user preset, and you don’t want expansion of options?
Or is the “history” dropdown in the Audacity command-line encoder sufficient for you as a preset, and we would keep the MP3 Options interface “simple”?
Gale
Again, I would like to be able to save presets under a name, as you can with ffmpeg export.
History just saves the recent ones. The last 10 could all be failed experiments.
Not just Lame, but also the external programs.
But you are ignoring the issue of lame “standard vs old” nomenclature.
That is something that could trivially be fixed. The current labelling encourages users to apply deprecated settings by describing them as “standard”.
I disagree. Most users will not look at or care about the LAME documentation (or look at our docs). “Old” and “New” or “vbr-old” and “vbr-new” would not be clear enough.
I don’t know where the word “standard” came from, but In older versions of LAME or some hard to encode material, “standard” may give the better quality result. So the implication that fast would reduce quality would then be correct. There is nothing to stop user installing an old version of LAME as long as it contains sufficient “symbols”.
Perhaps we should use both explanation and technical term:
or say what you will for “Legacy”.
As it says on http://wiki.hydrogenaud.io/index.php?title=LAME
reports of artifacts when using the new mode do exist
Gale
No details on the “reports of artifacts”, or which version they affected.
That remark was added in 2005 (http://wiki.hydrogenaud.io/index.php?title=LAME&oldid=6495 ) when it actually was “new”-ish.
I think such issues might have been addressed by now.
Note that like Lame itself, the Hydrogen wiki also uses the terms VBR-new and old, not Standard and Fast.
I make a point about this because for the last year I’ve been using “VBR-old”, taking three times as long and making files 30% larger than they needed to be, because I believed I was using the “Standard”, not cutting corners and using “Fast”.
Now I know better, only because I stumbled on an explanation of what the words really mean when looking up something else.
Just get rid of the word “Standard” when it isn’t and hasn’t been that for 10 years.
(It’s hardly “new” now either, but …)
I agree with this point and have argued in the past that the “standard” option should be removed as (in 2015) it offers no benefit over vbr-new.
Unfortunately resistance to removing that option is likely to remain until LAME officially declares vbr-old to be deprecated or obsolete.
The “Remarks” in the Recommended Encoder Settings clearly state:
the new mode is currently recommended due to both the speed and quality increases afforded by the new algorithm.
but unless you can find official documentation that explicitly states that vbr-old is deprecated or obsolete, I fear that we may be fighting a lost cause.
On the other hand, it seems that you are also arguing that all encoder options (including old, deprecated and sub-optimal options) should be available in Audacity.
If “the new mode is currently recommended due to both the speed and quality increases” isn’t good enough, what do they want?
Who chooses VBR-old deliberately, and why? I really would like to know. Not people like me who were confused by the terminology.
I’m pretty sure vbr-old has been obsolete for the last 10 years
But I would settle for it not being called “Standard”.
First this “Standard/Fast” is one of a very few Lame options are accessible in the export gui. Otherwise you have to choose a preset.
Again, I am looking at the freedom I have to choose options and save my own presets for ffmpeg export.
If we can’t have that, just let us create command lines and save them as presets.
An ephemeral, unnamed item in a list of previous commands isn’t that.
Now you have clarified you want MP3 user presets and not additional exotic MP3 options, I noted your “vote”.
Of course that does not mean that it will be done.
Evidence? That page is regularly maintained. They could have removed the reference to the reports if they were not true.
So what word do you suggest instead of “Standard”?
Gale
I answered that already. People with old versions of LAME that they prefer for some reason, or people with hard to encode material.
I assume you did not compare all your “standard” encoded MP3’s with “fast” re-encodings of the original material? I have done some listening comparisons and sometimes “standard” has given better results (less artifacts) to my ears, with the classical/soft rock genres I work with.
I agree the name “standard” is a (small) problem.
But not marked as such by LAME.
If we had a huge LAME dialogue like for “Custom FFmpeg options” then the huge LAME dialogue would include all options including those which you personally don’t like, such as --vbr-old.
OK, then you want presets in command-line export as well.
Gale
Yeah, I did. That’s how this all started.
But I am currently doing low bitrate spoken word, so my focus on saving bytes. Which is what VBR-new does.
If we had a huge LAME dialogue like for “Custom FFmpeg options” then the huge LAME dialogue > would > include all options including those which you personally don’t like, such as --vbr-old.
I don’t “dislike VBR-old”. I dislike it being presented as “Standard”.
I don’t want to prevent anyone from using it, as long as they know what it is.
OK, then you want presets in command-line export as well.
While a full-on ffmpeg -style dialog for Lame seems unlikely to materialise, just being able to save arbitrary command lines as presets would go a long way.
You could use it for weird Lame commands, or have it export a ringtone to email. Whatever.
And give it a name so you don’t have to hunt down your text scrap with all the options and escapes and codes.