Quote:
Originally Posted by leupi
I was hoping to take the sissy way out and do it with a GUI. Seems like I need to roll my sleeves up and use a script though
Can I use that script that you have to run on a whole directory as I have about 700 songs to do?
|
With a little modification. All the files are in one directory, right, and all the file names end in
.m4a? Assuming this is the case, save the following into a file in that directory called
convert.sh, putting it in the same directory as your m4a files:
Code:
#!/bin/bash
total=$(ls *.m4a | wc -l)
mkfifo myfifo.wav
number=1
ls *.m4a |while read m4afile; do
mp3file="${m4afile%.m4a}.mp3"
echo "converting $number of $total : $m4afile -> $mp3file"
lame --quiet myfifo.wav "$mp3file" &
screen -d -m mplayer -vc null -vo null -ao pcm:waveheader:file=myfifo.wav "$m4afile"
wait
let number+=1
done
rm -f myfifo.wav
Then open a terminal, change to the directory where this file is located using the
cd command. For example, if the m4a files and the convert.sh file are in the
music/m4a directory in your home folder, open a terminal and do this:
We need to make the file executable. Do this:
Code:
chmod u+x convert.sh
Incidentally, I found that very strangely, mplayer doesn't want to run normally from the script (although the same commands were working just fine from the command line). Anyhow, using
screen (which you must install) fixes that.
Quote:
Originally Posted by leupi
I am actually doing this for a friend and I did mine about 3 years ago and just ran some script (that I no longer have) on a directory overnight and next morning I had all of my .m4a files converted to .mp3.
|
Yeah, re-coding the files will take a lot of CPU time. Encoding mp3 takes a while and mplayer doesn't seem to efficient at de-coding the m4a files either. Overnight should do it though, unless you have some really massive about of audio to convert, or a very slow computer.
Quote:
Originally Posted by leupi
Can you explain to me what that script is doing? It does not mean much to me and I would like to understand what the individual parts are doing. I just bought a book on the Bash Shell (O'Reilly) a few days ago, would that explain what is going on there?
|
mkfifo is an ugly way to accomplish something which is usually very simple in shell scripts. Usually if you want to take the output of one program and process it with another program, you would use a "pipe". For example. Say I have a program which outputs all the phone numbers in my contacts database (lets call it "print_contacts"), I can take this large output and make it the input to a very commonly used program called grep, which prints only lines which match some pattern. I connect the output of the first program to the input of the second using a pipe, the syntax of which is the | character. For example:
Code:
print_contacts | grep Matthew > shortlist
...this will output only contacts which match the pattern "Matthew",saving to the file
shortlist.
It's a trivial example, but it explains one of the keys of building programs in shell scripting. Because of the design principles of the core unix tools, it is possible to build up really quite complex functionality in this way. Two important design principles are that all programs output and read normal text (avoiding program-specific binary formats where possible), and keeping functionality in small units which can be used to build larger more complex programs.
Ideally, if these principles were kept to, there would be a program which would read am4a file and output a wav file in the normal way, and then lame could read that output through a pipe and encode the mp3 file. It would be nice... here's how might look:
Code:
m4atowav myfile.m4a |lame > myfile.mp3
Sadly mplayer doesn't "do" regular output in the way which makes it possible to read from a pipe,so we have to use this trick of a fifo, which is a special file type which acts as a pipe and we can use it to connect the two programs. It's a somewhat advanced topic, and not a technique that is very often used, so I wouldn't worry about it too much. Suffice to say mplayer doesn't behave like a traditional unix program in ways which I would like...
If you want to learn shell scripting (and it's really worth it), have a look at this:
http://tldp.org/LDP/abs/html/
To understand the design philosophy of unix tools, I recommend reading this book:
http://www.faqs.org/docs/artu/