- Open a WAV file in the wave editor;
- Name it
- Save it in AAC format;
- Result: the name of the encoded file is
Mac or Windows?
There are also issues with decoding AAC if those “special” characters (e.g.,
’) are included in the filename.
Are you doing a ‘copy and paste’ for the re-name, or typing in the new name?
In my case, the filenames are inherited from the region markers in a montage. But they can be renamed manually afterwards.
It looks like having those special characters in the names of region markers that are then used to define the output path of ACC files actually affects the very contents of the ACC files. For instance, changing the level of the montage output would not be reflected in the contents of the files if their names contain those characters.
Hmm, I really doubt that because these are totally independent stuff.
This Unicode name encoding for AAC is on my to-do list for 11.1.20, but I can’t allocate time to look at it now.
I have come across something similar (not AAC) when doing a copy and paste on a Windows 10 machine from a document (word, rich text etc) that was created in OSX. The work around was to copy the name to a text file and then copy and paste it to the file name (these were ‘complex’ names that I didn’t want to type manually).
I only mention this in case it might work in your situation.
They certainly are! However the process of saving a file is directly connected with its name and may trigger errors at the OS level if there is something wrong with the name. Just a wild guess.
I was working on a long batch of AAC files when I ran into the issue. Didn’t have time to test it though.
This will be fixed in 11.1.20.
I’ve noticed something regarding this issue that may need additional attention: if I specify a location with a relatively long destination file path, I run into cases where WAV, FLAC, and MP3 files succeed in being rendered and saved, but AAC fail. The cause is the length of the path. If I choose a shorter path, the same AAC files do get rendered and saved. So the encoding issue, which tends to produce extra characters and thus lengthen the path, may still affect some parts of the underlying code. See if you can reproduce it and fix it.
Can you reproduce this with WaveLab 11.2 ?
If yes, give a concrete path example.
It may have been v11.1.20 when I ran into the problem (multiple times). I’m now on v11.2. If the problem crops up again, I’ll let you know.
Unfortunately, the bug I mentioned earlier is there and has resurfaced as I’m working in WaveLab 11.2.
C:\Users\XxxxxXxxx\Xxxxx\Xxxxxxxxx\000000 - Xxxxx xxxx - Xxxxxx Xxxx Xxxx\XxxxXxx\Xxxx\Xxxxxx\Xxxxxxxx\Xxxxxx Xxxx Xxxx - 00.00. Xxxxxxx [00 xxx - 0’00’’].m4a results in two stacked errors:
If I shorten the path to
C:\Users\XxxxxXxxx\Xxxxxxxxx\Xxxxxx Xxxx Xxxx - 00.00. Xxxxxxx [00 xxx - 0’00’’].m4a, render works as expected.
As noted earlier, this issue only affects AAC.
Well, I could not reproduce this issue with that path.
Is this really reproducible for a given path?
C:\Users\XxxxxXxxx\Xxxxx\Xxxxxxxxx\000000 - Xxxxų xxxė - Xxxxxx Xxxx Xxxx\XxxxXxx\Xxxx\Xxxxxx\Xxxxxxxx\Xxxxxx Xxxx Xxxx - 00.00. Xxxxxxx [00 xxx - 0’00’’].m4a (re-inserted two international characters that are part of the original path); otherwise, just render a WAV from a montage to a destination with the maximum allowed number of characters in the path for Windows (260) AND some international characters in it. It should work. Then do the same with an AAC. It should not work.
100 % reproducible on my machine: I can render WAV, AIFF, FLAC, etc. to the destination specified earlier, except for AAC, in which case I get two errors. I can PM you screenshots of the error dialog windows I get.
Yes, I can reproduce now. Must be a Fraunhoffer issue. I hope I can find a solution to it.
Follow-up: I used the shorter path to render the AAC files and then manually moved them to the destination with the longer path. WaveLab fails to open the AAC files from the latter destination and also fails to read the file properties in the Montage File Browser.
For the sake of further documentation, I’m currently working on a batch of files whose processing gets disrupted by ♭ and № in the filenames of AAC versions. I am able to complete the processing only by removing those characters from the filenames.