Audacity mangles filenames on export (BUG?)

[coordinatezero]

Hi. My Mac is running OS X 10.5.8 and this is all on the local drive.

I have a WAV file on the Desktop called JT7L - 20091101 - rehearsal- amp death.wav which I imported into Audacity.

I attempted to save it as an MP3 to the Desktop, using LAME. The "Save As:" field in the "Save MP3 File As:" dialog box shows JT7L - 20091101 - re#182C5D.mp3 and, when I click on "Save", it tells me that "JT7L - 20091101 - rehearsal- amp death.wav" already exists. Do you want to replace it?

I point out, again, that the target filename supplied by Audacity is of "MP3 files (*.mp3)" Format, and the filename as it appears in "Save As:" has no ".wav" in it, and ends with ".mp3". It's as if the "#182C5D" expands magically out to some other filename.

What's going on???

[kozikowski]

Two items. You used a forbidden character in the filename. Upper and lower case letters, numbers, underscore and dash. That's it. No other characters. Especially nuclear and evil is the slashmark.

I need to share files with machines in our company all over the world, so I don't use spaces, either.

Can I assume you're on an Intel Mac? Intel/Leopard and Snow Leopard no longer support Audacity 1.2.

I use 1.3.7 from here for my daily work...

Audacity 1.3.7 -- Mac
http://audacity.googlecode.com/files/au ... -1.3.7.zip

This is the developer nightly build...

Audacity 1.3 Nightly Build -- Mac
http://www.audacity.homerow.net/index.php?dir=mac%2F


Or you can go with the latest 1.3 download from the regular web site....

Audacity Current Release -- Mac
http://audacityteam.org/download/beta_mac

Koz

[billw58]

This appears to be a limitation of Audacity 1.2.6

Using 1.3.10 I created a new project, imported some audio, then exported it as a WAV with your exact filename: JT7L - 20091101 - rehearsal- amp death.wav. Then I exported it as an MP3 with no problem.

Switched to 1.2.6 and imported the WAV and my project name became: "JT7L - 20091101 - reh#5081C". Note that the name was truncated on import. Attempting to export to MP3 with the default name (which is the project name) resulted in the overwrite warning. Attempting to enter a longer filename crashed Audacity 1.2.6.

All this on a Mac G5 running 10.5.8.

Recommendation? As Koz said, upgrade to 1.3.9 or 1.3.10. I regularly use the latest nightly builds. The developers are into bug-squashing now, not feature-adding, so the releases get better and better every night.

-- Bill

[coordinatezero]

The funny thing is, at my company we're seeing this with FinalCut Pro, as well. My company makes a server product for collaborative video editing workgroups, and I'm one of the tech support guys, and I noticed this while running Audacity and thought "oh ho, so it's not our product, it's something Mac OS X based!".

The "#nnnnnn" number turns out to be the inode of the original file. I guess our question really is "what is it about Audacity 1.2.5 that changed in 1.3 that stopped that from happening?" We diff'd the source code of ExportMP3.cpp and found the calls to the "wx" widget libraries changed.

The question of "why is it doing this at all?" still remains. Considering the filename has no illegal characters in it (contrary to the first responder's assertion), what's triggering this? Why does it seem to kick in if the filename is over 27 characters? We're a bit confused.

Many thanks for giving this some attention!

[kozikowski]

Intel/Tiger takes Audacity 1.2.5 and PowerPC/Tiger takes Audacity 1.2.6. Until a short time ago, I was running both successfully.

Intel/Leopard or Intel/Snow Leopard can create multiple unstable conditions with Audacity 1.2 versions.


"#" is a Special Character in many lists and may create unstable conditions. If you stick to one computer platform and version, you will find many "illegal" characters that seem to work just fine and poo poo the whole idea, but if you change anything, upgrade, or try sending the files to an unknown computer, you may find the process seriously damaged.

Koz

[kozikowski]

I believe early Mac had a 127 character filename limit.

Koz

[coordinatezero]

I'm on an Intel MacBook running 10.5.8 and seeing this behavior.

To reiterate, since I'm not sure people are reading correctly: a filename longer than 27 characters gets truncated to:

substr(orig_filename,1,length(orig_filename)-length(hex_inode_num)) + "#" + hex_inode_num

E.g.:

filenamewithmorethan27charactersinit.wav

becomes something like:

filenamewithmorethan2#12345.wav
filenamewithmorethan#123456.wav
filenamewithmoretha#1234567.wav

Audacity developers! What is it about 1.2.6 that causes a freak-out on 27+ character filenames and makes Audacity rewrite the filename with the inode encoded? Is it the "wx" widgets? Is it something about Mac OS X? You obviously fixed the issue with 1.3, so what was the cause?

Thanks!

[kozikowski]

<<<I'm on an Intel MacBook running 10.5.8 and seeing this behavior.>>>

With an Audacity that's not supported on your Mac? The jump to Intel/OS-X 10.5+ caused Audacity 1.2 to do a great many bad things -- to the point that it's no longer useful in addition to being old and no longer developed.

If you have a filename problem with Audacity 1.3, then please bring it up. Audacity 2.0 Stable is in the wings and all the programming resources are being devoted to that.

Koz

[billw58]

We diff'd the source code of ExportMP3.cpp and found the calls to the "wx" widget libraries changed.

Note that in 1.2.6 the project name gets truncated with the inode number. So it's not necessarily anything to do with ExportMP3.cpp. Also note that I got a nasty crash when I tried to edit the exported MP3 file name to longer than 27 characters. I think it's something deeper inside Audacity 1.2.x.

Development on the 1.2.x branch has long been closed, so if you need to continue using it I'm afraid your only recourse is to avoid long file names.

Anyway, I'd still suggest you try the 1.3.10 nightly builds. http://www.audacity.homerow.net/index.php?dir=mac%2F
Scroll to the bottom to get the latest one. They're very stable. And have lots of useful new features versus 1.2.x.

-- Bill

[coordinatezero]

Kos, your constant repetition of "use the right version!" makes me think you're not reading my questions carefully. I think I need to be more specific. I'll happily run Audacity 1.3 on my Intel 10.5.8 Macbook, no problems there, but that's not what I'm asking about.

My question is, for the developers, WHAT MAKES IT ACT FUNNY IN THIS WAY? We're seeing this problem with our customers who are using FinalCut Pro and are running into this problem. The only other application I've seen this happen in is: Audacity. The Audacity folks make it clear they don't want to hear stuff like this directly at their feedback email, so I'm asking here instead --- if you're an Audacity developer, it would help us with OUR problem if you could say something about what changed between 1.2 and 1.3 in terms of filename handling, or if you even know what part of the OS X kernel or "wx" widget set is responsible for this.

I'm not interested in what version works on what system. Audacity 1.2.6 is happily working on my Intel mac, whether it should or not, and just happens to show up this weird filename mangling problem that clearly has nothing to do with Audacity itself, and merely the library routines it is calling, or some interaction with the kernel, and THAT is what I'm enquiring about. We figured "aha, maybe they know something we don't". There's little to no information on this anywhere on the net. (Perhaps someone out there can formulate a better Google search.) Our current theory is that there's something in Carbon that freaks out on certain long filenames (but not all), but we can't pin it down.

Thanks.