lame decoding to wav, entire /dir instead of one by one?
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
lame decoding to wav, entire /dir instead of one by one?
Ive just started playing around with lame to decode .mp3's to wav files and it works quite well.
I was wondering if there is a way to decode all *.mp3's in a directory with a single command, or if I have to continue one .mp3 at a time. I took a look at the man page but didnt find anything usefull (that I could see).
I tried lame --decode *.mp3 but that didnt work
just looking for a command with lame to be able to tell it to take all the mp3's in a directory and go ahead and decode them one after another.
thanks alot, that is exactly what I was looking for. And it works great. Im starting to slowly learn that the CLI does seem the way to go for alot of things!
how about the other way around? Can this work as well in the situation of encoding the .wav files of an audio cd to .mp3 in lets say 256?
I tried messing a bit with grip, but I kept getting errors about the rip configuration ever since I attempted to install software to encode to ogg.
<you could type 'for song in *.mp3; do lame --decode "$song"; done' and that should do it.>
This is very nice, and I wonder if it could be explained briefly.
We're setting up a 'for' loop ... Is 'song' & '$song' some kind of internal variable in lame? ... and I'm not sure of the reason for the "s around '$song'.
... and I assume this would have to be executed from withinthe directory where the mp3s are located.
After thinking about it, I think I do understand it somewhat. If you had a directory of mixed .mp3 & .ogg files to decode, the script could as easily read for X in (*.ogg,*.mp3); do lame --decode "$X"; done
I still don't understand the "s, tho. What would I be looking for in a manual for this sort of thing?
mipia, doing it the other way around is just as simple: for file in *.wav; do lame --alt-preset standard "$file"; done would encode all the files with a *.wav file extension in the current directory to mp3's using lame's very good standard VBR preset.
Bash loop basics: A for loop operates on a list of items. for file in *.wav will operate on all files with names that end with .wav in the current directory. I suggest you read the part on loops in the excellent Advanced BASH-scripting Guide. In fact, I always keep a copy of this guide on my laptop in case I would get bored or need to get something done quickly.
As for the quotation marks ("), they are needed for backwards compatibility with the "sh" shell (as opposed to the bash shell). If you program modern Bash, you would probably make sure you escape the variables like this instead: for file in *.wav; do lame --alt-preset standard ${file}; done
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.