Normalise with non-standard characters in file name[FIXED]

[Shaky]

I am trying to run a Normalise/file conversion chain, and am experiencing some odd behaviour.

Using an existing file ‘50% - Obsession.wav’ Audacity crashes every time I try to normalize, including when applied on a standalone basis (ie not in a Chain).

If I take the same file and copy/rename to something without the ‘%’ character it works fine.

Is this a bug and/or is there a workaround?

Many thanks!

[steve]

You need to be very careful with “special” characters such as “%” as they can have special meanings (you must have seen “%20” sometime in a web address - it’s a code combination for a “space” character). Also, Windows has quite extensive rules about characters that are “illegal” in file names: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
The safest approach is to always use “normal” characters - numbers, letters, space, hyphen, underscore, and nothing else. These characters are safe on all computer systems (with the exception of a few 3 / 4 character combinations on Windows (see previous link).

[Shaky]

@steve

You need to be very careful with “special” characters such as “%” as they can have special meanings (you must have seen “%20” sometime in a web address - it’s a code combination for a “space” character). Also, Windows has quite extensive rules about characters that are “illegal” in file names: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
The safest approach is to always use “normal” characters - numbers, letters, space, hyphen, underscore, and nothing else. These characters are safe on all computer systems (with the exception of a few 3 / 4 character combinations on Windows (see previous link).

Thanks Steve. I understand the point, however, the MSDN document makes no mention of the character “%”. Furthermore I have also had similar problems with ’ (single quote) previously, which is also supposedly unreserved.

Is it possible that file names are somehow incorrectly escaped internally in Audacity?

[steve]

I can look into this.
What exactly is in the Chain and what settings do those effects have?
Which version of Windows?
Anything else I need to know to reproduce the issue?

[Shaky]

@steve

I can look into this.
What exactly is in the Chain and what settings do those effects have?
Which version of Windows?
Anything else I need to know to reproduce the issue?

It doesn’t have to be in a chain in order to generate a crash; can be just using Normalise standalone with the only option checked being Normalise maximum amplitude to [-2db].

And the specific condition that seems to trigger it is with a file name “xyx % - xyz” (ie something [percent] [space] [dash/minus] something). I’ll add further instances if/when I come across then, and it doesn’t seem to matter what the audio format is.

I’m seeing this using Win 7 x64 Ultimate.

[steve]

How peculiar
Yes I can confirm that this is a bug.
It seems to be Windows specific and only appears to happen with the Normalize effect and when a track name includes a “%” character.

Thanks for the report, I’ll pass on the information so that it can be fixed.

While we’re waiting for it to be fixed, the obvious workaround is to ensure that track names never include a “%” character. As imported tracks inherit their name from the file name, this means that if you use Normalize in a chain and apply it to files, you will need to ensure that the file names do not contain “%” characters.

[Gale_Andrews]

@steve

I’ll pass on the information so that it can be fixed.

Thanks, Steve. We take crashes seriously, and as far as I can tell it has been fixed now in the source code, so will be fixed in the next 2.0.2 release.


Gale