Two (or more) bugs

Hi,

Today I wanted to record two sessions of about 1 hour with Audacity 2.2.0 which I have just downloaded from the official site. The way I did it was like this:

• Started Audacity
• Clicked “Record”
• …
• Clicked “Stop”
• Clicked on Save Project (in the Audacity’s format)
• Deleted the track (clicked on the little X)
• Clicked “Record”
• …
• Clicked “Stop”
• Clicked on Save Project As, saved under a different name in the same directory

What I got was that the second project save went ok, but the FIRST one was mangled: when I later tried to open the first one, Audacity complained about orphaned files (a lot of them). When I ignored the orphaned files, it turned out that the first project and the second project contained identical audio. You’ve read it correct: two projects, saved under different names, now contained the same audio data.

So I had the second audio, exported it ASAP in FLAC so I don’t mess it up and tried to figure out how to recover the audio from the first one.

It looked like Audacity could open individual audio files (*.au) from the project _data, and googling around showed that I’d need to order the files by their timestamps (why on Earth would someone generate random filenames for this purpose instead of sequential is beyond comprehension), and then concatenate every second one to get a single track of a stereo pair. Since my data is mono, just recorded as stereo, I just sorted the files and discarded every second one. This seems to produce the correct results.

Now, I’ve tested this by importing a couple of tracks into Audacity, doing Select->All, then Tracks->Align->End to end, and it works.

However, when I added all the tracks to Audacity (the computer has enough RAM), it crashed on any operation (I tried Tracks->Mix, and File->Save Other->WAV). Always. Without exception. Once it was able to produce a crash report, but as it didn’t save it in My Documents or in my user’s home folder, or in its installation directory, I have no idea how to get to it.

By trial and error, I’ve found that this crash happens if the number of tracks is larger than about 255 or 256. As long as the number of tracks I’m importing is less than 256, it works ok. So I solved my problem by importing batches of 240-ish *.au files, doing Select->All and Align->End to end, then Tracks->Mix and saving them as FLAC, then after I was done I concatenated all the FLAC files in the same way, so I’ve managed to restore the audio data.

When I restored it, I found that the restored audio - and remember, this was from the FIRST project saved - contained ALL of the audio data, for both sessions. So it looks like the second session continued to be recorded in the FIRST project’s _data, and when I did a Save Project As, BOTH the first project’s .aup file and the second project’s .aup suddenly contained only the information about the SECOND session, while the first project’s _data contained data for BOTH sessions. The second project’s _data contained only data for the second sessions, as expected. Weird, right? Like something in the Save Project / Save Project As code path mixes the two up.

So, the good news is that no data was lost, and the bad news is that… well, I know this is an ancient project, but come on… firstly, recording data to files and saving them in proprietary format (this .au is not the “standard” .au, I’ve checked, it’s got Audacity-specific headers and VLC cannot read them), then naming the files pretty much randomly when sequential naming would be fine (with a different suffix per channel, perhaps?), then using an 8-bit counter somewhere for the tracks?

As I couldn’t find a way to do a proper bug report on the website and the wiki, I’ve thought that at least writing this up in a forum would help future users and perhaps someone will get a lightbulb moment and know how to fix some of this.

I’ve thought that at least writing this up in a forum would help future users and perhaps someone will get a lightbulb moment and know how to fix some of this.

That works. You’ve been very thorough in your description. Easy access to the developers is discouraged because there are a great many instances of the program out there and all three developers would get swamped if they had to deal with every shebobble (technical term). The up side is the Audacity forum which functions much like an actual help desk with active elves across 9 time zones.

The way I did it was like this:

There is a little magic in the background. Audacity forms UNDO by remembering the whole show. When you UNDO, you just start looking at the show before this one. It doesn’t try to take apart the changes you made. Right after you deleted your first performance, you could Edit > UNDO and get it back. It never really went away.

why on Earth would someone generate random filenames for this purpose instead of sequential is beyond comprehension

It’s only beyond comprehension because you had a failure. Had you had a large, complex, healthy show, random names helps avoid inadvertent duplication of names.

But yes, it does hose anybody with a failure.

We have postings from other people with magic failures. For no apparent reason, the project either outright failed, or got damaged.

We do recommend Exporting as WAV (Microsoft) for safety if you can. Obviously, that doesn’t work if you have a multi-track performance or want to save your edit in the middle. Mind that Audacity Projects do not save UNDO.

As we go.

Koz

In “Edit menu > Preferences > Import.Export”, which option is selected for “When importing audio files”?

I followed your steps to reproduce on both the released 2.2.0 and the latest Release Candidate for the upcoming 2.2.1 (W10-CE laptop)

I cannot reproduce the error you report …

\

1. Started Audacity

2. Clicked “Record”

3. …

4. Clicked “Stop”

5. Clicked on Save Project (in the Audacity’s format)

6. Deleted the track (clicked on the little X)

7. Clicked “Record”

8. …

9. Clicked “Stop”

10. Clicked on Save Project As, saved under a different name in the same directory

11. Launch Audacity

12. File > Open Project-1 from step 5

13. Like you I get orphan block files (only 4 as I only made short recordings)

14. Unlike your case, my Project-1 was intact and complete, played fine and was operable

15. File > Open Project-2 from step 10

16. my Project-1 was intact and complete, played fine and was operable

I also repeated the tests substituting steps 2-3 and 7-8 (the recordings) with imports of pre-existing audio files.
Project-3 and Project-4 thus created were both fine and intact - and this time I got no orphan block files.

So I am puzzled by your report


If it was me doing this, particularly with non-repeatable recordings, I would be exporting WAV files at steps 5 and 10 (as Koz suggested)

Also I might be inclined at step 6 to open anew project with File > New or its shortcut Ctrl + N

WC

That shouldn’t happen, so I’d say that is a bug.

• At step (5), Audacity saves the first project and copies data from the tmp directory to the project’s “_data” folder.
• Steps 7 to 9 will add new blockfiles to project 1’s “_data” folder (because we are still “in” the first project.
• At step (10), Audacity creates a new project, and copies the data belonging to this project to the new project’s “_data” folder.
  At this point Audacity should clean up the “_data” folder of the first project, leaving only the data required by the saved state of project 1.
  Your description suggests that this clean-up is not happening (or not happening correctly), This ‘may’ be related to recent changes to how Audacity cleans up if the drive is full (just a guess).

I’ve only had time to test this briefly (on Linux), and the problem does not appear to happen hear, though that could just be that I’ve not tested sufficiently yet.

If the above issue is repeatable on Windows, then it needs to be logged on bugzilla - perhaps you could check that waxcylinder?

Ah but when I repeat these these tests on 2.2.1 RC1 (the current release candidate) I no longer get orphan blocks

Testing the same steps on 2.2.1 RC1 W10-CE
a) at step 13 I no longer get the orphan block files (presumably benefitting from one of Paul’s orphan block fixes for this release)

b) both projects are intact with no data loss an do data corruption,

All looking good in this respect for the upcoming 2.2.1

Peter.

Developer here. I tried all of that in 2.2.0. I can’t replicate the problem of the first-saved project becoming identical to the other. I do see the orphan block files.

And that was a known problem, new in 2.2.0 but now fixed in 2.2.1, whose Release Candidate will be very soon announced.

What I got was that the second project save went ok, but the FIRST one was mangled: when I later tried to open the first one, Audacity complained about orphaned files (a lot of them). When I ignored the orphaned files, it turned out that the first project and the second project contained identical audio. You’ve read it correct: two projects, saved under different names, now contained the same audio data.

So I had the second audio, exported it ASAP in FLAC so I don’t mess it up and tried to figure out how to recover the audio from the first one.

It looked like Audacity could open individual audio files (*.au) from the project _data, and googling around showed that I’d need to order the files by their timestamps (why on Earth would someone generate random filenames for this purpose instead of sequential is beyond comprehension), and then concatenate every second one to get a single track of a stereo pair. Since my data is mono, just recorded as stereo, I just sorted the files and discarded every second one. This seems to produce the correct results.

Now, I’ve tested this by importing a couple of tracks into Audacity, doing Select->All, then Tracks->Align->End to end, and it works.

However, when I added all the tracks to Audacity (the computer has enough RAM), it crashed on any operation (I tried Tracks->Mix, and File->Save Other->WAV). Always. Without exception. Once it was able to produce a crash report, but as it didn’t save it in My Documents or in my user’s home folder, or in its installation directory, I have no idea how to get to it.

By trial and error, I’ve found that this crash happens if the number of tracks is larger than about 255 or 256. As long as the number of tracks I’m importing is less than 256, it works ok. So I solved my problem by importing batches of 240-ish *.au files, doing Select->All and Align->End to end, then Tracks->Mix and saving them as FLAC, then after I was done I concatenated all the FLAC files in the same way, so I’ve managed to restore the audio data.

When I restored it, I found that the restored audio - and remember, this was from the FIRST project saved - contained ALL of the audio data, for both sessions. So it looks like the second session continued to be recorded in the FIRST project’s _data, and when I did a Save Project As, BOTH the first project’s .aup file and the second project’s .aup suddenly contained only the information about the SECOND session, while the first project’s _data contained data for BOTH sessions. The second project’s _data contained only data for the second sessions, as expected. Weird, right? Like something in the Save Project / Save Project As code path mixes the two up.

So, the good news is that no data was lost, and the bad news is that… well, I know this is an ancient project, but come on… firstly, recording data to files and saving them in proprietary format (this .au is not the “standard” .au, I’ve checked, it’s got Audacity-specific headers and VLC cannot read them), then naming the files pretty much randomly when sequential naming would be fine (with a different suffix per channel, perhaps?), then using an 8-bit counter somewhere for the tracks?

As I couldn’t find a way to do a proper bug report on the website and the wiki, I’ve thought that at least writing this up in a forum would help future users and perhaps someone will get a lightbulb moment and know how to fix some of this.

I regret you went through all this trouble.

I have been contemplating how we might implement easier recovery in cases like this. (You won’t see that yet in 2.2.1 though.)

The file organization may seem strange, but as previously explained here, part of the rationale is to implement undo and redo, while sharing much of the file data between undo states. Also to support cutting and pasting, so existing blockfiles are mostly reused, except near the boundaries of the edit, and we can simply record a different sequence of blocks. So even if new block file names were generated sequentially, the correct permutation of them would still not always follow that in the general case.

Paul