Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

iTunes LAME Encoder available Apps
I have written a simple script to bridge the gap between iTunes and the LAME command line encoder. It will automatically handle ID3 tags, and makes LAME quite a bit easier to use.

A previous hint has instructions for installing LAME.

This is the first version and hasn't been extensively tested by others, so any input would be appreciated.
    •    
  • Currently 3.00 / 5
  You rated: 4 / 5 (6 votes cast)
 
[15,458 views]  

iTunes LAME Encoder available | 38 comments | Create New Account
Click here to return to the 'iTunes LAME Encoder available' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
thanks!
Authored by: Embro on Dec 10, '01 06:38:36PM

The script makes it easy! Did you notice your not encodeing the total number of tracks into the tags?

You should make the default option --r3mix :-)



[ Reply to This | # ]
thanks!
Authored by: njitkoff on Dec 10, '01 07:40:34PM

I just noticed that. LAME doesnt support that tag, but i may try to work around it.

--r3mix is _my_ default setting, but someone suggested i make them fairly simple by default.



[ Reply to This | # ]
thanks!
Authored by: mzajac on Dec 10, '01 08:47:04PM

Beautiful.

I've been using my own crude AppleScript hack that does the same thing. I will now be using your script (--r3mix is also my option of choice). Thank you.

I presume you left out the genre because Lame only accepts particular genres. I tried to work around this by presenting a selection list, but applescript seems to crash when it tries to work with the list of 148 genres.



[ Reply to This | # ]
Hmmm.....
Authored by: stonefish on Dec 10, '01 07:14:15PM
For me, the script doesn't seem to work. I ran the script from the Scripts menu in iTunes, and it got to the point where it asked me for the info and made the playlist, then did nothing.

I ran the script from the Script Editor, and came up with a "Folder not available in this operating system version" error when it got to this point:

set theScriptFile to (((path to temporary items from local domain) as text) & ".iTunes-LAME.scpt")

The part in italics is the part that is highlighted when the error message appears.

I am using MacOS 10.1.1, so I'm not sure if this message is entirely valid. What happened? Has anyone else had this problem?

[ Reply to This | # ]
Any suggestions
Authored by: njitkoff on Dec 10, '01 08:08:16PM

This has been bothering me occasionally for weeks

Anyone know why AppleScript somtimes says

"Folder not available in this operating system version" when using "path to X"

usually (path to desktop folder) works, but i'd rather stick the child scripts somewhere out of the way.



[ Reply to This | # ]
More iTunes scripts
Authored by: mzajac on Dec 10, '01 09:02:54PM
There's plenty more about scripting iTunes at Doug's AppleScripts

[ Reply to This | # ]
better lame mp3's
Authored by: dewme5 on Dec 10, '01 10:59:01PM

minus one little small problem with the script, everything has gone great. nick did just what i wanted to do, but couldn't get to run right. i'm soo thankful for a X lame encoder with out all the command line boredom. (i've got A LOT of cd's that i want to rip)

now for my question. is there anything for OSX that is like exactaudiocopy for windows? something that gets rid of over 99% of the clicks, pops, skips and such? I have a few older cd's that have a couple small scratches in them that could really use some of this technology.



[ Reply to This | # ]
Updated
Authored by: njitkoff on Dec 10, '01 11:03:05PM

I fixed a few problems. A newer version is availible:

http://blacktree.com/scripts/iTunes-LAME.sit.bin



[ Reply to This | # ]
Ripping speed
Authored by: Tomster on Dec 11, '01 03:25:35AM

I'm new to LAME and wondered how much faster ripping with it was compared to using the iTunes. Or is it a matter of sound quality? I wonderd what advantage LAME had over iTunes.

Thanks



[ Reply to This | # ]
Ripping speed
Authored by: njitkoff on Dec 11, '01 08:31:22AM

For most, the primary motivation is quality. Using the "--r3mix -q0" settings, my iBook 500 can barely manage 1x :)

The upside of this is that the command line encoder can run happily all day long in the background while I use the computer for other stuff.



[ Reply to This | # ]
it's quality
Authored by: dewme5 on Dec 11, '01 11:05:21AM

lame is a better quality encoder then the fruenhoffer or ogg codecs. if you are interested in most everything there is concerning mp3's, and getting the best out of your time creating mp3's, go here and read up!


http://www.r3mix.net/



[ Reply to This | # ]
it's quality
Authored by: shacker on Dec 12, '01 10:20:09PM
O'Reilly's MP3: The Definitive Guide is also excellent. ;)

[ Reply to This | # ]
Ripping speed
Authored by: Thistledown on Dec 12, '01 12:59:11AM

I've noticed I can rip about .90x play speed with --r3mix with lame 3.89 on a TiBook 550. What I don't understand is why my 1 Ghz P3 can encode the exact same wave file at 5.4x play speed. Windows takes 34 secs and the mac takes 3min 50 secs. I would expect my Mac to be close to Windows, but it's much slower.



[ Reply to This | # ]
Ripping speed
Authored by: james_sorenson on Dec 13, '01 12:56:11PM

Is the Windows machine ripping the file using the same settings as the mac? The r3mix setting in LAME will severely tax your processor as it tries to make a perfect-sounding file as small as absolutely possible. Default settings for iTunes and most Windows players are usually set for lower quality (therefore more speed).

I have now modified this ingenious script for my purposes. I made an additional script that re-encodes a selection files to a different directory that uses smaller-file settings (so I can stuff more music in my MP3 player). Man, how long did it take to engineer this beast? Nice work!



[ Reply to This | # ]
Ripping speed
Authored by: Thistledown on Dec 14, '01 09:44:35AM

I ripped one track using iTunes to a wav file. I copied this file over to my windows box. I used "lame --r3mix infile outfile" to encode it both on the mac and the pc. The pc did it in 30 secs at 5.x speed. The mac took 3.x min at .9x speed.

The mac is running 3.89 (alpha?/beta?)
The pc is running LAME version 3.90 MMX (alpha 8, Oct 23 2001 10:14:08) (http://www.mp3dev.org/)

Perhaps it's the MMX. I don't know. I'll see if I can find a version of 3.89 and run the test again.



[ Reply to This | # ]
Ripping speed
Authored by: Thistledown on Dec 14, '01 11:16:02AM

Ok. I ran a test with two tracks this morning. I used ExactAudioCopy on a pc to extract 2 wav files from a CD. I transfered the wav files to my mac and here are the results.

800Mhz Pentium III PC running Windows 2000
LAME 3.89 MMX
Track 1
2.75x speed
1:31 time

Track 2
2.3x speed
2:17 time

LAME 3.90 MMX
Track 1
3.8x speed
1:01 time

Track 2
3.8x speed
1:22 time


550 Mhz TiBook running OS 10.1.1
LAME 3.89 (beta 1, 12/03/01) installed via fink
Track 1
.85x speed
4:34 time

Track 2
.80x speed
6:25 time

Clearly the Windows version is much faster which just irks me to no end. There are some obvious optimazations in the 3.90 MMX version. I'm surprised that a December build is as slow as it is on my mac. If anyone discovers a new build or optimization for LAME on OS X, let me know.



[ Reply to This | # ]
Ripping speed
Authored by: marmoset on Dec 18, '01 04:00:51PM

IIRC, the x86 versions of LAME use inline hand-coded assembly
in some performance-critical sections, LAME for other CPU
architectures falls back on routines written in C.
Unless someone goes through and does an equivalent
amount of optimization for the PPC version, using LAME
to compare the platforms' speed is not going to be a fair
fight.



[ Reply to This | # ]
simple interface for the command-line
Authored by: c15zyx on Dec 11, '01 04:03:41PM

I have also been slightly annoyed at the steps needed for encoding many files, as i copied the command text into a folder name and used to just paste it into the terminal when i need to encode, saves lots of typing.

However, i have since written a c program (written & compiled in the terminal :-] ) that asks you for id3 tags and passes the output to lame transparently. An added bonus is that the output can be based on the inputted tags, for example the popular "%artist - %title.mp3". Since almost everybody uses the same settings for all their mp3s, this is a convenient and very quick way to encode. Right now it's fairly simple, but I guess I could adapt it for batch encoding. The interface looks like this:

Enter the track #:
05
Enter the track title:
Some Title
Enter the track artist:
Artist goes here!

then it passes it onto lame with my usual settings- simple huh? If anyone is interested I could develop it further.

--c15zyx



[ Reply to This | # ]
: in track error
Authored by: joec on Dec 13, '01 01:11:35PM

I get an eror whenever a ":" is in the title of a track I try to encode. Is this a script error or a more general lame error? It just winds up skipping the track, so I have to go back and encode it in another way..

Example:
execution error: Can't make file Vital Information:Where We Come From:09. Craniac Trilogy - Part 3: The Implant.mp3" of application "Finder" into a alias. (-1700)

Other than that everything works great!!!



[ Reply to This | # ]
It's not a bug, it's a feature.
Authored by: stonefish on Dec 13, '01 07:18:12PM

It's not a LAME 'problem', per se, but more of a system-wide aversion to using ':' or '/' in a file name. ':' is used in MacOS to denote a directory; For instance, my Music folder is located at My Computer:Documents:Music. That can also be read as My Computer/Documents/Music.

If a ':' or '/' is part of a file name, an application that is searching of the file would run into a little trouble. For instance, if an MP3 file is named 'Artist:Track.mp3', then a program will look for the file 'Track.mp3' in the folder 'Artist', instead of a file named literally 'Artist:Track.mp3'. To prevent a problem of this, LAME (and other applications) wisely prevent people from naming their files with those characters.



[ Reply to This | # ]
It's not a bug, it's a feature.
Authored by: james_sorenson on Dec 13, '01 07:40:58PM

This is a classic "Mac vs Unix" file-system problem. The ":" is a Mac directory delimiter, while "/" is the Unix directory delimiter. Want to have some real fun? Go and create a folder in the Finder and name it "Test/This." Now, open the terminal and list where that directory is located. It appears as "Test:This." When mixing Unix with Applescript, these changes become a SEVERE headache. I honestly wish there was a setting in Applescript to make all file references in Unix form.

Anyhow, I got around this problem by replacing his makeunixpath function with my own (posted earlier on this site). It accounts for all these problems. However, it took some work to put it in. His script sends the path quoted, while mine creates the path using escape characters. I suppose I could show my modifications to his script with his permission.



[ Reply to This | # ]
It's not a bug, it's a feature.
Authored by: njitkoff on Dec 14, '01 09:58:23AM
I'd like to see your workaround, however i have updated the script to handle both slash, backslash, and colon. (and probably broke some stuff as well) http://www.blacktree.com/scripts.html

[ Reply to This | # ]
Mac Unix script
Authored by: james_sorenson on Dec 14, '01 12:08:35PM

My mac to unix path conversion applescript subroutine is already posted here in MacOSX hints. Your conversion routine will still choke if it comes across a name with quotes, but that is extremely rare in CDs.

Your extensive error-checking for writing the tags is intriguing. It seems it would have been a little easier to just assign all tag information through iTunes (rather then as Lame arguments). Is there a problem with that?



[ Reply to This | # ]
Mac Unix script
Authored by: njitkoff on Dec 14, '01 01:00:49PM

I thought about that, but since it was already there i just left it in. I was partly worried about things making it back into iTunes to be finished. I am not completely secure about the whole script->shell->script affair. it would be a lot easier though.....



[ Reply to This | # ]
Mac Unix script
Authored by: njitkoff on Dec 14, '01 01:03:11PM

oh, and i thought i fixed the issue with quotes. what version are you looking at?



[ Reply to This | # ]
It's not a bug, it's a feature.
Authored by: Anonymous on Nov 26, '02 06:30:15PM

I'm running version 1.0.4b of the script and I'm getting errors on a slash.

I did find a way around it - renamed the CD in iTunes, ejected and reinserted.

Its ripping fine as we speak. (someone from apple should add some altivec enhancements)



[ Reply to This | # ]
Wonderous Quality!
Authored by: bab on Dec 13, '01 10:52:57PM

Thanks for pointing the way to LAME and making it so easy to use.
I'm a bit a an audiophile, so sound quality is more important to me than disk space. Yet, setting my LAME variables to match my iTunes settings, I get equal file size, yet smooth, liquid, non-tiring sound from my Monsoon M-700s. Much better than the native iTunes encoding.
Thanks again!



[ Reply to This | # ]
Improved quality
Authored by: c15zyx on Dec 14, '01 05:38:28AM

as of the time of this post, a new version of lame has just been released, and includes the setting

--alt-preset standard
the faster, slightly lower quality version is:
--alt-preset fast standard

these presets have gone through much experimentation and testing and many improvements have been made, superceding --r3mix. see www.hydrogenaudio.org or www.r3mix.net/forum/ for details.

if you are using --r3mix to encode quality mp3s you should think about switching to either of the two above.



[ Reply to This | # ]
More '/' Problems
Authored by: kkthompson on Dec 14, '01 01:37:08PM

I just ran into a similar problem. Couldn't get it to work at all for a while (even crashed script editor!), but then I figured out where it was failing. The disc I was using (only one I had here at work) was given the genre Electronica/Dance. The slash was giving it fits... or was it because it's not in your genreList?



[ Reply to This | # ]
More '/' Problems
Authored by: njitkoff on Dec 14, '01 03:11:08PM

It worked for me whon i tried it (on 0.9.5). I will look into it. I am probably going to bypass lame's tags entirely in the next version, so it should work anyway.



[ Reply to This | # ]
A more robust version
Authored by: james_sorenson on Dec 15, '01 03:41:50AM
Okay, I picked your script apart, added some stuff I needed, and took out some of the stuff that I don't. You can get the new script at: http://homepage.mac.com/james_sorenson/FileSharing.html Look in the scripts directory for Convert to HQ MP3 with Lame.scpt Here is what I changed: (1) Added my own Mac to Unix path conversion. This one is the most robust one I have made so far (will it ever end?). You can throw every screwball character at it except high-bit characters. This includes all punctuations, slashes, colons, tildes, etc. I still can't figure out high-bit characters, though. (2) Used iTunes for tag support exclusively. Take a look at how I did it. Each track you import will make its own applescript containing the link to the original track and labeled with the track database ID. Once lame has created the file, it will call this applescript file. That file will directly copy the tag information from the source track to the new track. No more worries about weird characters in the tag details! The applescript files are deleted once all tracks have been processed. (3) Added the ability to put new files into a genre folder, as well as artist and album. (4) Took out stuff for making multiple playlists. I sort everything by tags. (5) Added ability to tailor how the new file is named. You can number what order the artist, album, track, and title are listed in the file name--separated by dashes. (6) Added "macfixfile" function to simplify the created file names. Basically, it makes sure that the new filename will be void of high-bits, quotes, slashes, and tildes. This just makes it a lot more compatible with MP3 devices. The tag information inside the file will be un-touched, though. Shortcomings: You cannot delete the original file from the playlist until the conversion is done, or there will be nothing to get tag information from! In theory, I could copy all tag information to the applescript file, but I was too lazy to do it that way. Here is where I'd put my disclaimer that I hold no responsibility to what anguish any existing bugs may cause you. Once again, thanks for showing us how to do this! It's a relief to be able to use iTunes cddb tag support with lame's MP3 encoder engine! Jim

[ Reply to This | # ]
A more robust version
Authored by: kkthompson on Dec 16, '01 03:56:56PM

It looks like you have a hard coded path left in the code. When I execute, I get an error:
File Macintosh HD:Stuff:Users:sorenson:Library:iTunes:iTunesLame-345.scpt wasn't found. I don't know much about scripting, but it looks like it's being stored in the scriptfile variable...



[ Reply to This | # ]
A more robust version
Authored by: james_sorenson on Dec 16, '01 05:27:36PM

You are correct that I hard-coded some directories. They are stored in the property declarations at the very beginning of the script. I like to have direct control on where my temp files are going. However, it looks like he updated the script to include these abilities anyway, so use his.



[ Reply to This | # ]
New Version (again)
Authored by: njitkoff on Dec 16, '01 05:13:14PM

Based on james_sorenson's suggestion, I have bypassed LAME's tags entirely. The new version is at <a href="http://www.blacktree.com/scripts.html">http://www.blacktree.com/scripts.html</a>



[ Reply to This | # ]
Slight modification
Authored by: evands on Dec 17, '01 08:51:51PM

Better ability to selectively encode tracks off a CD with this script can be obtained with a very slight modification near the beginning of the on run section:

set trackList to {}
repeat with i from 1 to (count every track in thePlaylist)
if (track i of thePlaylist is enabled) then
set the trackList to trackList & {track i of thePlaylist}
end if
end repeat

This way, the tracklist comprises only the checked tracks; I had problems with it not figuring out which ones were selected to be encoded and insisting upon encoding the whole CD.



[ Reply to This | # ]
0.9.9
Authored by: njitkoff on Dec 18, '01 03:22:06PM

Getting dangerously close to 1...

Misc new features and bugfixes

http://www.blacktree.com/scripts.html



[ Reply to This | # ]
RE: 0.9.9
Authored by: lngtones on Dec 25, '01 09:58:53AM

hmmmmmm
Well the script worked great for the first cd....
but now, when I first try to run it, it creates the playlist and does nothing.
Then if I try again it will launch LAME.

But once it's done encoding. I'll get:

Writing LAME Tag...done
--------------------------------------------------------------------------------
Adding to playlist and fixing tags.
execution error: Script doesn't seem to belong to AppleScript. (-1752)

And the songs won't be added to the playlist, so I have to go and add them and edit their ID3 tags by hand :-( Ugh.

Anyways

I'm using 0.9.9 of the Script, Version 3.91 alpha 1 build of LAME, and the --alt-preset standard option. Any ideas on what I can do to fix this?

Thanks



[ Reply to This | # ]
RE: 0.9.9
Authored by: njitkoff on Dec 25, '01 03:25:03PM

try removing
iTunes-LAME.scpt
iTunes-LAME.sh
from the Library:iTunes: folder. they sometimes get stuck



[ Reply to This | # ]