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


Click here to return to the 'It's not a bug, it's a feature.' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
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 | # ]