Audacity Forum

After a lot of searching, I now learn that Audacity is unduly sensitive to the characters one uses to name one's project. Meanwhile I had been told that there was an error saving my projects, and as a result a lot of work went down the drain.

The message basically says ...Perhaps your disk is full. What nonsense in 2010! Before 2.0 is released can someone update this error message? New users need to be told two things: one, they should try renaming the project using the plainest characters; second, they should be advised that exporting to a lossless format (AIFF or WAV) will effectively preserve their work too.

<<<they should be advised that exporting to a lossless format (AIFF or WAV) will effectively preserve their work too.>>>

I know it doesn't seem like it, but the elves on the forum have been trying to get the developers to improve things like that forever. My favorite change would be in the Save Project dialog. [You are not saving a sound File!]

Your above comment is a little harder. That does not work if the user has more than one stereo track. Then each stereo track must be exported separately and suddenly the instructions don't fit on an automobile bumper sticker or Post-It Note any more.

Someone will correct me, but the only uncompressed multi-channel sound format is Broadcast WAV which very few people support.

I'm going to post a link to this on the Improve Audacity forum.

By the way, I don't think odd filename characters are an Audacity problem. All Audacity does is go out and tries to save MyMusic12/3/98.wav sound file and it's the operating system that throws up. You can't do that in Photoshop or Excel, either.

Koz

Diligently, I found one reference to forbidden characters nested somewhere in the forum. If I hadn't found that I would have trashed the program and never looked back. I'm sure countless users have done that already and we just never hear from them.

I assumed this problem was universal, which is why I didn't post specifically to the OSX sub-forum, the environment in which I work. The characters in question work fine for me in all other programs, so I still assume the problem is with Audacity, or at best with the way Audacity interacts with a Mac system.

My suggestion about including the suggestion to export just has to do with offering a possibly useful workaround to someone who might be at wit's end, facing the potential loss of hours of work.

There was also supposed to have been an auto-save function, which does not seem ever to have kicked in. I'm assuming now, for the same reason. (How about a meaningful error message then, to the effect, we're scheduled to be doing an auto-save now, but can't because of your file name. Change it, human, or else.)

Sigh.

VHF wrote:The characters in question work fine for me in all other programs, so I still assume the problem is with Audacity, or at best with the way Audacity interacts with a Mac system.

Which characters specifically were the problem?

This needs further testing. I'm on a Mac, 10.5.8 PPC, Audacity 1.3.12-Feb 14. I've just successfully saved projects named:
test/this/name (saves unchanged)
test:this:name (the save dialog changes the ":" characters to "-" - a legacy issue from the days when the Mac OS used ":" instead of "/" for path names)
test-this-name? (saves unchanged)
test-this*name? (saves unchanged)
But I got the "disk full?" message with
testthis*name?

The error with autosave may have to do with not going through the Mac save dialog, which apparently filters the "/" character. Without that filtering, a file name with a slash in it may be interpreted as a partial path name.

A similar issue appears with Export Multiple, which does not go through the Mac save dialog. Using "/" characters in labels (which are used for the file names) results in a "directory not found" error. Strangely, AFAIK, the export multiple function does not trap the "/" character as illegal, but it does trap "*" and "?".

This may also have to do with the cross-platform basis of Audacity - certain characters are illegal in file names on different OS's.

VHF wrote:How about a meaningful error message then, to the effect, we're scheduled to be doing an auto-save now, but can't because of your file name. Change it, human, or else.

Further to that, filtering/replacement of all illegal characters whenever anything is saved (a project or an exported file) would be nice. That way you could send your project to someone working on a different OS and it would work.

-- Bill

<<<I assumed this problem was universal, which is why I didn't post specifically to the OSX sub-forum, the environment in which I work.

There's flag down on the play and the home team takes a time out. And you did this without testing it? Even a little bit? We provide individual operating system portions of the forum because it saves us time and work not having to start asking you what kind of computer you have. If everything works out, the appropriate elves will automatically be dispatched to help you.

We really like hard data, thanks.

And speaking of hard data...

<<<The characters in question work fine>>>

Such as? In detail, plz. The whole list.

<<<for me in all other programs>>>

Such as? Program names and versions and operating system version?

<<<I still assume the problem is with Audacity, or at best with the way Audacity interacts with a Mac system.>>>

It's possible, but we can't approach the developers with no data. They don't just frown on that. They've been know to smite us with lighting bolts.

[WHY HAVE YOU COME TO US, ELF?]

Not good being smitten, trust me on that.

Ow.

Koz

kozikowski wrote: ... but we can't approach the developers with no data. They don't just frown on that. They've been know to smite us with lighting bolts.

[WHY HAVE YOU COME TO US, ELF?]

Not good being smitten, trust me on that.

Ow.

ROFL - and I sympathize - me too, ouch

This is really silly. The leading lights wrote the code, or at least have access to it, and don't need us to tell them which characters are rejected when in Save mode. Billw58 has the same system I do, and since he seems to be more scientifically inclined, I'll let him do the experimentation if he's so inclined. For me, to mention that there is at least one other application that does not have this issue (probably because their code is more up to date...) speaks to an Audacity issue.

All I care about is that benighted error message, which seems to be leftover from 1922.

I have established the scenario. A new user reviews the Preferences and sees an auto-save function active by default. She imports a sound file, and its name appears without alteration as that of the project, with the suffix .aup, and feels safe. As a newbie, she does not realize that this thing that plays back is not a sound file (as koz says), and that simply exporting the file as such could save a lot or even all of her work. All she knows is, she's in a Catch-22, where the system is telling her her multi-terabyte disk must be full, so the file is not being saved!

Oh, well. So, I guess I have to live with my work from two minutes ago (the default time in the auto-save preference) in the auto-save file, wherever that is, and she quits. Looks for any trace of her hours of work. None to be found.

Not a pretty picture. And, as I said, has probably turned any number of new users fast into former users!

But did you determine which characters specifically were the problem? That would really help.

-- Bill

VHF wrote:The message basically says ...Perhaps your disk is full. What nonsense in 2010!

Yes indeed - a poor example of error messaging, but perhaps not quite as bad as: As a Mac user VHF you will have been sheltered from these infamous error messages which come courtesy of the worlds biggest software company.
I don't think it's any excuse, but I'm not a programmer so I've no idea what's actually going on at machine level, but logically, if the system is just telling Audacity "no, you can't write that data", then it may be difficult for Audacity to give a more meaningful message.

VHF wrote:I now learn that Audacity is unduly sensitive to the characters one uses to name one's project

That was certainly true before full Unicode support, but for the current 1.3.x version the main limitation in file naming is the operating system.
On Linux, of the characters available on my keyboard, the only one that I cannot use in a file name is the slash (/). The forward slash is used for path names, so if I tried to write: "new-file-17/2/2010" as a file name, the operating system would be looking for a (non-existent) folder called "new-file-17" with a subdirectory called "2".

On Windows the conventions for file naming are far more restrictive and are described here: http://msdn.microsoft.com/en-us/library ... S.85).aspx
In short, you cant use any of the characters: * < > : " / | ? Integer value zero, ASCII NUL character, characters whose integer representations are in the range from 1 through 31, two consecutive dots, and any others that I've missed. In addition, there are rules according to the file system, for example the MS-DOS FAT file system supports a maximum of 8 characters for the base file name and 3 characters for the extension. On more recent file systems this 8.3 limit is removed but there is still a limit on the maximum path length (256 characters?). In addition, you cannot use the following names: CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 and you cannot start a file name with a space. File names on Windows are not case sensitive so Desktop.wav is identical to desktop.WAV

Although Audacity itself now supports Unicode, that does not mean that all of the components and libraries that Audacity uses will also support Unicode. For example, the names of Nyquist plug-ins must be alpha-numeric. Nyquist is a separate program from Audacity, developed by other people (as is Lame, FFMpeg and others). It is included in Audacity as it provides additional functionality (support for Nyquist plug-ins). Just as we would not expect the Audacity developers to rewrite the operating system on which Audacity is running, we cannot expect them to rewrite all of the shared libraries that Audacity uses (though they have been known to fix the occasional bug in other libraries).

There are additional naming problems that occur as a result of the internet. You've probably noticed that some file names have the characters "%20" in the name. This is a result of ASCII encoding (of a space) that occurs somewhere between a person typing the name and it being downloaded. Other substitutions can also occur, and while it is usually harmless, in some cases it can break things.

The upshot is that it is always safest to use "standard" characters when naming anything on computers. ("standard" characters are a-z, 0-9, hyphen and underscore). This should be a matter of common practice for people familiar with computers.

As a matter of interest, how does your web browser display this word: の検索結果
It should look something like this:

VHF wrote:they should be advised that exporting to a lossless format (AIFF or WAV) will effectively preserve their work too.

We do our best to inform users of this at every possible occasion. [sigh]

VHF wrote:There was also supposed to have been an auto-save function, which does not seem ever to have kicked in. I'm assuming now, for the same reason. (How about a meaningful error message then, to the effect, we're scheduled to be doing an auto-save now, but can't because of your file name. Change it, human, or else.)

Now that is a much better error message, I like it
However, the choice of file name should have no effect on whether or not Audacity performs an "Auto Save".
On Linux, the autosave file is (by default) in /home/<user>/.audacity_data/AutoSave/
(I'm not sure where it is on other platforms - anyone?)

The file name will be something like: "New Project - 2010-02-17 17-03-55 N-1.autosave" until the project is successfully saved.
On attempting to save the project with an invalid name (with a forward slash) I get the error message: The Autosave file is not affected and still exists.

If I then purposefully crash out of Audacity (kill the process), the AutoSave file still exists, the temporary data is still in the temporary data folder, and restarting Audacity can automatically recover the project.
Anyone want to try on another platform?

billw58 wrote:Further to that, filtering/replacement of all illegal characters whenever anything is saved (a project or an exported file) would be nice. That way you could send your project to someone working on a different OS and it would work.

Not sure about that Bill. What if I want to be a bad boy on my Linux box and name a project That is perfectly valid on my machine, so why mess me around?

kozikowski wrote:It's possible, but we can't approach the developers with no data. They don't just frown on that. They've been know to smite us with lighting bolts.

[WHY HAVE YOU COME TO US, ELF?]

Not good being smitten, trust me on that.

Ow.

ROFL
You speak wise words Elf.

VHF wrote:This is really silly. The leading lights wrote the code, or at least have access to it, and don't need us to tell them which characters are rejected when in Save mode. Billw58 has the same system I do, and since he seems to be more scientifically inclined, I'll let him do the experimentation if he's so inclined. For me, to mention that there is at least one other application that does not have this issue (probably because their code is more up to date...) speaks to an Audacity issue.

The only problem that I can find with naming files on my machine is that I can't use a forward slash (which is exactly the same for all programs). I can even name files in Japanese! Unless we can say to the developers "look there's a problem - here it is" then nothing is going to happen. With older versions of Audacity there were clear problems with naming files, but now I see nothing, in spite of looking for fault. So as far as Linux is concerned - nothing to report.

stevethefiddle wrote:Not sure about that Bill. What if I want to be a bad boy on my Linux box and name a project

He said "HELP?".AUP

That is perfectly valid on my machine, so why mess me around?

Try saving a project with the name:

Hesaid Help.aup

That should be valid on your machine but I'll bet Audacity will choke. Is Audacity treating the backslash as a path delimiter or an escape character?

Try doing an export multiple with label names containing "?" or "*" - Audacity won't let you, and offers to change those characters to underscores.

No time right now, but later I'll test what happens with autosave on Mac when the project name contains a slash character.

To determine the "correct" behaviour by a "well-behaved" application on Mac I'd use TextEdit - written by Apple, so has the best chance of following the rules. TextEdit has no problem saving a document with the name "testthis/file.txt". AFAICT the only invalid character in a Mac file name is ":", and the Mac save dialog will not even accept them. Downloaded files containing colons have the colons changed to slashes before they are saved.

-- Bill