MP3 transcoding in Emelfm

Forum: User Feedback
Topic: MP3 transcoding in Emelfm
started by: ke4nt1

Posted by ke4nt1 on April 14 2005,19:51

I've got lame transcoding some mp3's in emelfm for me,
so I can load up my usbkeys for my DSL carputer.

Most of my rips are at 320 vbr , which is overkill for both
the carputer, and the ride home.. 160's will do nicely.

So, I archive the 320's onto dvd-r's for later use..

Once I have a selection to goto the carputer, I make them
transcode into 160 or 128.. I'm using this in emelfm to do it.
( as a button option )

" lame --mp3input %f -h -v -b 160 {160}.mp3 "

which works , but leaves me with a smaller file called
{160}.mp3 .. It seems I can't use the %f variable twice
in the same statement.. Is there a way I can actually make
the filename be created at the same time the new file is made ?

e.g. ABC.mp3 becomes ABC-128.mp3
XYZ.mp3 becomes XYZ-160.mp3

I'm guessing I'd have to make a script to do this, and make
emelfm run the script, rather than try to do it as a button
option within emelfm..

It is nice to see a song I want, click on it ,
and get a 128 bit ready-to-go file for the USBkey in seconds..
( without having to go back and rename it )

Any Ideas ?

73
ke4nt

Posted by cbagger01 on April 14 2005,22:16

This may sound obvious, but my first place to look would be to look at the emelfm documentation / home page / google for information.

But if I were doing it, I wouldn't bother and just write a small script to build a new filename from the original string parameter "$*".

maybe something like:

!/bin/bash
lame --mp3input "$*" -h -v -b 160 "160_$*"
exit

It is possible to add the 160 as a suffix to the output filename but it will require some string manipulation to squeeze it in between the filename and the .mp3 file extension. sed might be a good choice for that.

Posted by mikshaw on April 14 2005,22:16

I'm guessing you can probably use %f more than once, but maybe it gets screwy when you try to create a new filename using %f as the base. I haven't got emelfm right now to do any tests, so the only thing that i know would definitely work is a script.

#!/bin/bash
filename=$1
newfile=`echo ${filename}|awk -F .mp3 '{print $1}'`
lame --mp3input ${filename} -h -v -b 160 ${newfile}-160.mp3

Not tested, but it's something to try. It'd be added to emelfm with "scriptname %f".

Posted by clivesay on April 14 2005,22:44

In Emelfm %{} is the sytnax where you are prompted for a new filename. I use it for repacking .dsl files.

Does this help?

Chris

Posted by ke4nt1 on April 15 2005,16:32

While clivesay's idea does work,
I would still have to manually enter filenames every time..

..so , the script looks like the way to go..

... thinking a step or two further ahead ...

If I wanted to process an entire repository of stuff ,
( after I've backed up the good 320 VBR versions to DVD-R )
What would be the trick to making your script suggestions
work recursively thru hundreds of sub-dirs ?

Where I could start the script in sub-dir e.g. " XYZ BAND " ,
and have it process ALL the mp3's in every album under
the XYZ BAND dir, from whatever bitrate they are now to whatever I choose,
and write to a similar filename on the drive,
and preferably deleting the older version..

That would probably curb my bandwidth, and save drivespace.
(similar to icecasting, without the overhead of re-encoding
to a lower bitrate on-the-fly ..)

73
ke4nt

Posted by clivesay on April 15 2005,17:13

Are you wanting to modify all bitrates or just the ones above 160?

Posted by ke4nt1 on April 15 2005,19:18

I'd like to have the option to do whatever I choose
with a large stash of files...

e.g. - a low-width streaming icecast = 64k/mono
e.g. - a med-width streaming icecast = 96k/stereo
e.g. - a high-width streaming icecast = 160k/stereo
e.g. - some 128 bit versions for the car/personal player/etc.

Drivespace is really, really cheap these days.
So, making multiple pools of a group of cuts is no biggie.
Preserving bandwidth is a must,
and anywhere I can save cpu cycles is a good thing.

Again, these are just copies ,
as I have all the "good" stuff backed-up onto discs..

Thinking something similar to SU's bittorrent-gui.
( without the gui , for now )
1. Pick the sources
2. Pick the bitrate
3. Pick the destination
4. Hit GO!
and then go make coffee.......

I'm betting there is already a front-end to do this,
and I haven't found it yet, that uses the same tools
like lame, mpg321, oggenc, mp3info, etc...

73
ke4nt

Posted by cbagger01 on April 15 2005,22:08

If you write a script, please be careful on how you handle your parameters.

For example:

filename=$1

will not work if your filename contains a space character.

but

filename="$*"

should work.

It shouldn't be too hard to build a script that does the same thing using a directory name as the argument instead of the individual filename.

Posted by mikshaw on April 15 2005,23:04

filenames with spaces suck. I don't use them, ever, and have no idea why people like them.
If i run into a situation where spaces cause a script to fail, then i'll fix it, but usually i don't bother until the situation arises. Also, the "$*" will work in this instance, but will not work so easily in scripts using multiple parameters....another reason to consider dumping spaces. =o)

I'd say a function would be useful for recursive directories, so you can just call that function for each level you go. Again, this is untested.

Code Sample

encode_files() {
the code mentioned earlier, or something similar
}
find_files() {
for this_dir in $1/*; do
[ -d "$this_dir" ] && find_files $this_dir
encode_files
done
}

Are the files being saved into the same directories? If so that's another thing to consider, to prevent the same files being reencoded.

Posted by clacker on April 16 2005,01:17

I agree about spaces being a problem. The best I could come up for emelfm button code was this:

echo %f | xargs -n 1 | xargs --replace=foo lame -b 96 "foo" "96-foo"

It handles re-encoding all of the selected files, but only if they have no spaces. It puts a prefix on the file name, so I could see a problem with prefixes stacking up quickly. You could easily have a base name for the files, and then change the prefix and -b switch for the different rates so that's not really a problem.

I thought I should have been able to use 1 xargs command but I needed two. I had to load the gnu-utils.dsl file first. busybox xargs didn't cut it.

EDIT:

an even better way is this:

ls %f | xargs --replace=foo lame -S -b 96 "foo" "96-foo"

it handles multiple files like the previous one, but also handles files with spaces in their names. using the -S switch in lame keeps the ncurses garbage away from the emelfm window.

Posted by cbagger01 on April 16 2005,03:33

I try to avoid spaces in filenames as much as possible.

HOWEVER, when you are working with mp3 files that are ripped automatically from audio CDs using a ripper program that connects to the Internet to retrieve the artist / album / songname information, the Internet database will generate output filenames that will contain spaces in between the words from the song title.

So unless you also write a little utility script that converts all of your " " into "_" for the filenames, or unless you patch the source code of the ripper program (assuming that it is open source) and recompile, you will be dealing with filenames that contain spaces.

My preference is to make the conversion utility script smart enough to properly handle them but it appears that you and clacker have already done the job

Posted by cbagger01 on April 16 2005,04:43

I tried fooling around with emelfm a little bit and it does a better job than expected of passing a filename with a space over to the script.

Give this one a try. You can only convert one file at a time because it passes the output directory down to the script as the second argument.

I did not test it with lame but the rest of the script works fine when I substitute the "cat" command instead of lame.

Code Sample

#!/bin/bash
#
# /opt/tcode/tcode160 - A small Emelfm script to transcode a single mp3
# file into a new 160kb mp3 file in the other directory
# window pane.
#
# This new mp3 filetype association action COMMAND should be created in Emelfm:
#
# /opt/tcode/tcode160 %f %D
#
# Do NOT select multiple mp3 files at the same time when using this command.
#
# Script begins here
filename="$1"
output_path="$2"
newfile=`echo $filename | awk -F .mp3 '{print $1}'`
lame --mp3input "$filename" -h -v -b 160 "$output_path/$newfile-160.mp3"
exit

Posted by mikshaw on April 16 2005,04:55

The "other directory pane" is brilliant. Very simple and effective way to specify a target directory.

For multiple files, a "for i in %f" loop can work, but in this case it might take some work. I'm not even sure that works with spaces.
What happens when you do something like this:
for i in "$1"; do
echo "$i"
done
Does it mess up files with spaces? (again, i don't have access to emelfm at the moment.

Posted by clacker on April 16 2005,11:52

cbagger01, that's a great idea using the %D to get the path of the directory of the inactive pane. I modified my button script to use that idea. Now it handles file names with spaces, multiple file selections, and puts the converted files in the inactive pane's directory. It' works fine and it's short, but it is a little cryptic:

ls %f | xargs -i lame -S -b 96 "{}" "%D/96-{}"

the ls part puts the file names on separate lines. %f is the list of selected files in the active emelfm panel.

The xargs command runs the same command for a bunch of files. xargs -i replaces every occurance of {} and replaces it with the file name. The files are in quotes to handle files with spaces in there names.

The -S switch in lame keeps lame from using ncurses which filles up the emelfm output window with text and control charecters. The -b 96 switch sets the quality of the mp3. I kept the 96-*.mp3 format, although if you're putting the output into a different directory it might not be needed.

It still requires gnu-utils to be loaded first.

Posted by cbagger01 on April 17 2005,03:48

I think we have a winner.

Clacker's one line solution should do the trick because ke4nt1 uses gnu-utils most of the time.

If not, a for loop is also an option.

Finally, it is possible to put the whole thing into a script but I would need to double check my bash tutorial.

Basically, you would still pass the %f and %D down to the script and you would detect the total number of arugments passed.

Then you assign the last arugment as the output path and then you loop to (i-1) where i is the total number of arguments.

Or better yet you make the %D your FIRST argument and your %f your second argument and that simplifies things quite a bit.

Something tells me that a person who tries to do this in MSWindows with an MS-DOS batch file would be pulling his hair out

Posted by ke4nt1 on April 17 2005,05:21

Actually, I'm playing with them both..
Still finishing my backups before I do any REAL DAMAGE

Then I can play away... These are great, guys.. tnx a mil..

Yes, I am currently running my main box as a poorman's/frugal hybrid install,
booted with grub, with a full compliment of extensions loaded at boottime,
gnu-utils, dsl-dpkg.dsl, xfree86, nvidia, and many other favs and personals,
and the persistant home and opt dirs.. Includes the repository in full..

" I'm so happy, I could jump for joy!..."
... from 'Chitty, Chitty, Bang, Bang'

I did run AVG recently on my latest backup of the entire repository..
Another time-wasting exercise...

cbagger01 ! 1893 posts!?! good work!
I think it's time to plan a party.... or a roast :cool:

73
ke4nt