Encode/Transcode selected WAV/MP3 files to MP3 using LAME

Buttons/Scripts
,
1

Use this button definition to easily encode/transcode wave or mp3 files to mp3 using LAME encoder (free). Please change the path to lame.exe according to your installation. Hitting the button will encode all selected files to the destination folder.

<?xml version="1.0"?>
<button display="both" effect="gray">
	<guid>{9CE8D1E0-DEB3-4709-9212-D79474B8754B}</guid>
	<label>Encode MP3 (to destination) - Quality: VBR 4</label>
	<icon1>12</icon1>
	<function type="batch">
		<instruction>"C:\__CHANGEME__\lame.exe" -V 4 --vbr-new {filepath$} {destpath$}{file$|ext=mp3}</instruction>
		<instruction>pause</instruction>
	</function>
</button>

Hope this is interesting for you. Please give feedback.

LAME can be downloaded from several sources (ask google!). Official site: lame.sourceforge.net/index.php

1 Like
2

For decoding a MP3 File to WAVE you can use LAME, too:

<?xml version="1.0"?>
<button display="both" effect="gray">
	<guid>{9CE8D1E0-DEB3-4709-9212-D79474B8754B}</guid>
	<label>MP3 Dekodieren</label>
	<icon1>12</icon1>
	<function type="batch">
		<instruction>"C:\__CHANGEME__\lame.exe" --decode {filepath$} {destpath$}{file$|ext=wav}</instruction>
		<instruction>pause</instruction>
	</function>
</button>

See the documentation of LAME for other command line options (quality, ID3-Tags, etc.).

3

If you want to transcode a MP3 file to a lower bitrate (i.e. you have a 320 CBR file and you want it to be 128KBit VBR) you can use the first command, too. But LAME will not write the ID3 Tag in the destination file for whatever reasons.

Here's a little extension to the command. Just paste this line after the LAME command:

"C:\_PATH_TO_id3cp_\id3cp.exe" {filepath$} {destpath$}{file$|ext=mp3}

It will just copy the source file's ID3 Tags to the new encoded file! :slight_smile:
The needed program for this is attached to this thread.

Have fun!
id3cp.zip (268 KB)

4

I have split the discussion that was in this thread, about variables and DOS windows, into a separate thread here:

[Variables and DOS windows)

Once the discussion results in a finished button please post it here, but let's keep ongoing discussion out of this area so people can easily find buttons, rather than talk about buttons. :slight_smile:

5

Final button:

This will encode files from source to destination. The selected encoding quality will be used for all files!

<?xml version="1.0"?> <button display="both" label_pos="right" separate="yes"> <label>Encode MP3</label> <icon1>12</icon1> <function type="batch"> <instruction>@set var = {dlgchoose|Select encoding quality:|VBR ~165 kbps (4 - medium)=-V 4 --vbr-new+VBR ~190 kbps (2 - standard)=-V 2 --vbr-new+VBR ~240 kbps (0 - extreme) =-V 0 --vbr-new+CBR 128 kbps=-b 128+CBR 160 kbps=-b 160+CBR 192 kbps=-b 192+CBR 320 kbps=-b 320}</instruction> <instruction>____ENTER_PATH___\lame.exe &quot;{$var}&quot; {filepath$} {destpath$}{file$|ext=mp3}</instruction> <instruction>Pause</instruction> </function> </button>

6

Very neat!
That is cleaning up my MP3 encoding menu a lot :wink:

7

I like this feature a lot, but just some questions....

Encoding MP3 to WAV will not getter better quality.
Reencoding an MP3 to MP3 using Lame would IIRC lower the quality even more.
:confused:

8

[quote="Devilder"]I like this feature a lot, but just some questions....

Encoding MP3 to WAV will not getter better quality.
Reencoding an MP3 to MP3 using Lame would IIRC lower the quality even more.
:confused:[/quote]

  1. Decoding MP3 back to WAV will NOT bring you back original quality (MP3 is compressed audio and not lossless - you will always get the quality of the MP3 when decoding)

  2. You shouldn't re-encode a MP3 (this means loosing more quality as the source-mp3). Except you want to save space on a MP3-Player for example (I always re-encode higher quality MP3 to VBR 160 (LAME Preset 4) for my player).

Also LAME will bring you best results with VBR Preset 2 (~190kbps). At CBR 320kbps you won't hear a difference between MP3 and WAV.

9

I know this is a very old thread, but it was exactly what I needed.

One question, though. I can't get it to work to convert from ADPCM .wav files to .mp3 files.

It does, however, work perfectly when converting from regular PCM .wav files. Just not ADPCM .wav files.

Is there any way to modify the code to make it work for ADPCM files? (I guess that would be a function of the Lame.exe encoder, though, right?)

Thanks.

10

If lame cannot read ADPCM, then you need to convert your files to regular PCM first (I guess).

It looks as there is a tool called sox.exe, which is capable of doing that:
stackoverflow.com/questions/2495 ... -using-sox

11

Tbone, Sox looks promising. I'll give it a try. Best hope is that I can find way to incorporate Sox into a DOpus button that would make use of the {allfile} or {allfilepath} command arguments, of course. I'm old enough to have learned and recollective enough to still be reasonable proficient at writing code for DOS batch files, but given my venerable age and that age's condition of advancing decrepitude which gives increasing notice of the passing of time and all that that entails, I'd rather not be using up my time these days writing -- ugh! -- DOS batch file code, what with its lovable replaceable % and %% parameters and gotos and :labels and REMs and whatnot, as fun as all that was back in the old days when writing batch files was cutting edge on our $5000 256k RAM 5 MB hard drive PCs. (Oh. Fixed disk. I should have said fixed disk.) Hah! Yes, I'm that old. But I digress ... as is my perogative at my age. Hah again! Tbone, thank you for the tip. I'm gonna make this work. :slight_smile:

12

You can make it! o)

Why do you think it needs to use {allfile}? I don't see that currently, but we'll see. o)

13

Tbone, I have a little 1" x 4" pocket notes recorder, and each time you record a new "note to self" or whatnot, it stores that note in a separate .wav file. To save the files to your computer, it connects to it via a standard USB cable, and since its internal recording "mechanism" is simply a standard flash drive, it presents itself to my PC exactly the same as if I had plugged in a thumb drive, i.e., as a new drive letter on my PC. The .wav files on the recorder are named sequentially as rec001.wav, rec002.wav, etc., and you then just copy them onto your PC -- using DOpus, of course -- just the same as if you were copying files from one drive to another. (I think you get the gist, eh?)

At any rate, my PC is then left with many, maybe even dozens and dozens and dozens of .wav files (said in my best Carl Sagan voice), and I'd just as soon convert them to .mp3 files just to save disk space. (Although with terabyte drives nowadays it probably doesn't matter anymore to just keep them as .wav files, still the old habits and all that.)

The only audio software I currently have on my PC that can convert from ADPCM .wav files is Audacity, but with that program I have to do them one file at a time, Audacity not having any kind of command-driven interface (as far as I know). So, not good. Takes too much time, and is pretty boring after the first file (or even after the zeroth file).

So I'm assuming that in order to pass a list of multiple files -- dozens and dozens and dozens, even -- to Sox, a DOpus button would have to make use of the {allfile} or {allfilepath} command arguments when I have multiple files selected in a DOpus lister.

So, that's why. :slight_smile:

(BTW, my little pocket recorder is the Techerific Rad Recorder. It's great! If ever I go into espionage, I will not have to get a different one, that's for sure.)

Thanks again for the help. Any friend of DOpus is a friend of mine. :slight_smile:

14

You're assumption is well thought, but wrong. o)

There's no need to use {allfile} just because multiple files are involved. Usage of one or the other always depends.
In my recent wav -> mp3 fiddling, I went for {filepath} and launched multiple lame processes at the same time (as much as files were selected). Each process runs with "idle" priority, so they do not affect system performance noticeably, even though all cpu cores are under heavy load encoding audio data. Whenever {allfilepath} is involved, it's very likely that the tool you are about to launch has support for multiple filenames to be passed on the command line. If it does not, then you're back to {filepath} very quickly. o)