#1683 Audacity editing from RG appears broken

[musewhirl]

This bug is in v23.12. The way in which it is broken does not make any sense though, and seems like it would not have been noticed earlier. I myself don't often edit segments directly from RG using Audacity, but did some just prior to the release of v23.12 and the workflow was flawless before that.

Steps to reproduce:
1. Opened an audio file in Audacity
2. Edited the audio
3. Saved it back to the same file in the RG directory
4. NB all while RG is open, as I've done in the past

In RG the audio sounded like really loud noise drowning out the underlying correct audio, which could just barely be heard if your ears can take the volume.

I loaded the the same file in Audacity and the file sounded fine there, just like when I had edited it and previewed it. I decided to restart RG and listen again. I got the following error dialog:

Locate audio file dialog:
Could not find audio file:
/blah/rgdir/rgfile.wav
at expected audio file location:
/blah/rgdir/
Locate Missing File, Skip Audio File, Cancel File Open
Which would you like to do?

NB: Missing feature. There is no way to select the filename or directory in that dialog. One has to eyeball it and then visually check the RG directory with a file manager.
Feature request: Users should be able to select at least the filename and directory if not all the text, so that matching long filenames is easier, and pasting them when reporting errors here is easier too.

Fortunately, since I was returning to a session which had audio files in 2023, but before the v23.12 release, the new 2024 file stood out from the rest. RG was identifying that file and claiming it was not there. That is what makes no sense. I at first thought that under the covers it was looking in the wrong place, and providing wrong information...but that does not explain the corrupted audio heard before I had even closed RG. Next:

I tried Locate Missing File
1. Select an Audio File dialog dropdown:
2. It opened showing nothing in the RG directory, but its dropdown had "Requested File", which although in that directory according the the filemanager, RG was not showing it
3. Selecting the "WAV files" dropdown option shows the file is actually there, i.e. even according to RG's own dialog
4. All files option is ditto...the file is there
5. I picked the file anyway, now that it was visible

In RG:
1. There is no sign of file on a track.
2. There is no sign of the file in the Audio File Manager

No idea what RG had done. And when quitting RG does not ask whether to save, but on opening the cycle begins again with the missing file dialog.

This time I tried: Cancel File Open
Error dialog: Error while parsing the file "Audio file not found"

RG does not open the session, nothing else to do here.

So, tried: Skip Audio File:
1. Warning dialog: Skipping a file will remove its audio segments from the composition
2. I clicked OK, because there was obviously nothing to remove,
3. RG opened and no sign of segment on track
4. No sign of audio in the Audio File Manager.

Try Loading the file using RG's own Audio File Manager
1. Open Audio File Manager,
2. Selected the Load Audio file option
3. Navigated RG to the same file it claimed was missing.
4. RG loaded the file with "conv" as part of its name.
5. Inserted it into the track and it played correctly

Nothing wrong with that audio, which I thought might be in some format unfamiliar to RG, but acceptable to Audacity.

Repeated the whole exercise again with the new conv file as the source, once saved by Audacity, it too no longer played except as noise...i.e. broken again. And the rest is as above.

Try saving from Audacity to a different directory
1. I saved the Audacity changes to a different directory
2. Used a file manager to copy the file back to the RG directory with RG still on the session as usual.
3. Still broken...instantly.

Try closing RG before updating the file
1. I saved the file from Audacity to a different directory.
2. Closed RG first
3. Copied the the file to the RG directory.
4. RG opens and complains it can't find the file, even though it's the same name.

That was supposed to be a last ditch workaround and this was totally unexpected.

The simple original step was working flawlessly in RG v18.12, so I had no need to test all the subsequent versions above. This problem is in v23.12, but I cannot test the intermediate RG versions because other bugs blocked that path until this new version.

With this behavior, it's not clear whether RG does anything negative to the session directory as part of whatever is happening when the audio file changes. I don't think it does but I had to dump the session and forfeit all the work because I could not risk it.

From the above, the only workaround is to use RG's own load audio file to reload the file into RG every time. The only benefit to double clicking an audio file is the convenience of opening that particular one in Audacity first time around. Once in Audacity, saving the file with the same name is now not an option. A new name must be chosen. RG itself must then be used to load the new file and insert a audio track. At that point the old segment can be deleted, and finally the corresponding audio file removed using the Audio File Manager, none of this rigmarole necessary previously.

Is this a new workflow and expected behavior i.e. having to always load the audio with no direct editing of the files in the RG folder? And if not, can any of this be reproduced at you end?

It also just occurred to me during this post that since RG was informing me of what it found along with errors and warning by dialogs, I did not look at the actual logs to see if anything different was occurring there. If time permits, I will watch the logs while carrying out the supposedly simple first scenario and post the results.

[musewhirl]

Although v18.12 worked flawlessly with respect to this bug, there one was thing which I thought harmless at the time and which could be connected to what's happening now. Especially in light of my comment about the loud noise when RG blew well above 0 dbFS when playing the file saved from Audacity.

In v18.12, although playing fine, I did notice it took some time for the peaks seen in the segment to appear. Only from memory I recall that even though audio was there, the audio segment was totally empty, even of the usual horizontal line meaning no audio. But if you scrolled horizontally i.e. refreshed that area, the normal peaks would show up. Or you could open RG some time later, and everything not only looked OK but still sounded fine too.

But with this apparent bug around in v23.12, I wondered if peaks could be related? Anyway, I brought forward that watch of the logs mentioned in the last post.

While editing and saving the file via Audacity, there was no response in the logs except when Audacity was opened. Now I know RG is going to complain when I play that segment, but it noticed nothing during the overwrite. NB After hitting play, I stopped almost immediately because I still had not made adjustments to my environment for loud noise. This is the result:

[AudioPlayQueue] This tends to be the last thing you'll see on a normal exit.
[RosegardenMainViewWidget] slotEditSegmentAudio() - starting external audio editor
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "fact"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "PEAK"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "fact"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "PEAK"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "fact"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "PEAK"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "fact"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "PEAK"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "fact"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "PEAK"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "fact"
[RIFFAudioFile] RIFFAudioFile::scanTo(): skipping chunk:  "PEAK"
[SoundDriver] SoundDriver::initialiseAudioQueue -- new queue has  7  files
[SequencerThread] run(): Sequencer status changed from  0  to  1
[JackDriver] stopTransport(): resetting m_haveAsyncAudioEvent
----------------------------------------------------
Profiling points:

I then, threw that session away, recorded the segment again, but did not use Audacity for editing. I just recorded and saved. I played the segment and it was fine of course. I didn't actually add that log here, because it didn't mention peaks and while playing normally had a lot of output. I even closed RG, and opened it with the cursor still at the start of the newly recorded segment to see what is normally logged on play. Normal, with no mention of PEAKs right after RG says "the last thing you'll see on a normal exit":

[AudioPlayQueue] This tends to be the last thing you'll see on a normal exit.
[SequencerThread] run(): Sequencer status changed from  0  to  1
[JackDriver] stopTransport(): resetting m_haveAsyncAudioEvent
----------------------------------------------------
Profiling points:

Maybe it's nothing i.e. the peaks are already taken care of in the unedited segment but I thought I would mention it.

[musewhirl]

This bug shows up in another way, without even using Audacity as described above:

Steps to reproduce:

1. Simply rename an audio file in the RG folder
2. Open RG, and the error dialog indicating a missing file appears as expected
3. Select "Locate Missing File" file and select the renamed file
4. The error dialog reappears immediately claiming the file is not in the folder...it is referring to the original filename i.e. not the one selected by the user.

The expected behavior was in RG v18.12 i.e. for RG to accept the file selected by the user as the missing audio file. This is probably related to the issues previously described while editing with Audacity.

There appears to be no workaround:

1. The "Locate Missing File" option becomes a locked loop unless of course you put the original filename back via a file manager
2. The "Skip Audio File" is also a kind of locked loop. Whenever RG is opened, it will complain about that missing file, so you're stuck with a Skip until you comply with the renaming
3. "Cancel File Open" means you won't be doing anything with that session