I just ripped my copy of Tool's 1996 album, Ænema, encoding using LAME 3.96, and it didn't encode the title song, because of the non-standard character Æ in the title. So I chopped that character off the name of the wav file - so the output would have been named
Tool--13--nema.mp3
but still sent it to a directory named for the album. Again, LAME 3.96 wouldn't encode, because there was still a non-standard character in the output path. So I changed the directory to
\1996--nema\
and the output file name to
Tool--13--nema.mp3
and now the encoding worked.

I tested this with LAME 3.96 using --preset medium and --preset standard. It appears the codec, irrelevant of the command line, can't handle this character. Here's sample error message from the CMD window:

Can't init outfile 'C:\Music\wav\Tool\Tool--13--ªnema.mp3'

although that character doesn't look like a superscript 'a' in the CMD window, it looked like something weirder, and only looked like a superscript 'a' after I copy it to notepad.

Also, LAME 3.90.3 can handle outputting the character Æ without any problem, and it's handled other nonstandard characters - such as an e with an accent over it (think of U2's song Discothèque).

fyi...

[edit: U2 song accented è]

Unfortunately, this is a widespread problem with computer programs. Just ask some users from non-english speaking countries what happens when they dare to use their native (non-standard ASCII) characters like äöüßøæñëåèé in file names etc.

Unicode support is supposed to solve this problem. (good example: foobar2000 )