Re: [Audacity-devel] Bug: Export as WAV leads to file corruption when overwriting existing file (current cvs version is still affected!)

[Gale (A. Team) <ga...@au...>]

We haven't heard from Michael Burrian as far as I know, but Dawson very
kindly checked this extensively for me on Linux with files up to 2 GB
without finding a problem. I was therefore going to remove it from the
Checklist, assuming Michael (Chinen) had fixed it. However I've noticed
Audacity seems very erratic here on Windows XP in deciding how to
rename/whether to delete the renamed original. So I decided to try and
figure it out, and in doing so I ended up on three occasions with complete
silence in a 600 GB exported file, with the original file being deleted. 

If I import a 600 MB file, and export it once to the same file name in an
otherwise empty folder, there seems no problem. Audacity renames the
original file with "-old1" appended to the base name (for example: music.wav
becomes music-old1.wav), then a new file is created with the old name
(music.wav). I can exit Audacity and repeat this experiment exporting to a
new folder without problem. 

So now to test just the renaming and deleting, I imported a 20 MB
"music.wav", exported it, then repeatedly did a single edit and re-exported
it. This is what happened:

Export 1: old file renamed with "-old1" suffix and retained 
Export 2: old file renamed with "0" suffix and deleted 
Export 3: old file renamed with "0" suffix and deleted
Export 4: old file renamed with "-old2" suffix and retained
Export 5: old file renamed with "0" suffix and deleted

The exported files were always OK. I noted that on OK'ing the overwrite, the
file was renamed, even though I had still to do the metadata step to start
the export. So if I cancel the metadata step, the original file then no
longer exists. Shouldn't the overwrite prompt come last, or the rename be
left until the metadata step is actioned?   

At this point I stopped and quit Audacity. There were now three 20 MB files
in the export folder: music.wav (the edit from export 4), music-old1.wav,
and music-old2.wav. I relaunched Audacity and imported a 600 MB WAV and
exported. I was expecting the file to be renamed with -old1, but it was
renamed with "0", and deleted after the exported file was written. This file
was the correct length, and played, but total silence. I deleted this
corrupt file, exited and relaunched Audacity, imported another 600 MB WAV
and exported. Rename was to -old1 (retained) and the exported file fine. I
then edited and re-exported three times more, getting "0", "0" and "-old2"
suffices, and the exported file was fine. I did another export, got "0"
suffix and the exported file was silence.  

I repeated similar steps the day after, exporting repeatedly into a folder
which already had other files, and got a silent file the first time the
suffix was "0".
   
I find it very hard to see the pattern here, except that the "0" rename is
implicated. To me, it looks if the whole rename/delete routine needs looking
at. I can see some logic of retaining the original file at the first
overwrite, but not what happens with subsequent exports. I think it would be
better really just to have a single rename suffix "old" while exporting,
then delete the renamed original - it is what the user asked for. That's if
we can guarantee the new file is written properly.  

As for the checklist, this was (Linux only) P2, and it looks as if it will
have to remain at least at that rating, or even be promoted to P1, until we
understand it better. Meantime, does anyone on other OS'es have time to test
exporting and re-exporting into the same folder, and observe the
rename/delete behaviour? 



Gale 



Michael Chinen wrote:
> 
> I forgot to email the list to say that I believe I fixed this bug, but
> could
> not test it since it was only reproducable on your platform. If you could
> check the cvs head I'd be much obliged.
> 
> Michael
> 
> On Thu, Sep 25, 2008 at 3:51 PM, Michael Burian
> <mic...@sb...>wrote:
> 
>> Gale Andrews wrote:
>> > I'm Cc'ing to the original enquirer, as he won't be subscribed here.
>> > I assume your setting on the Import/Export Preferences of Audacity
>> > is the default "read uncompressed audio files directly". Is that so,
>> > and does setting that preference to "make a copy" stop the corruption
>> > in the overwritten file?
>>
>> Yes, when choosing "copy" / "safest" settings there is no corruption.
>>
>> >
>> > And are you saying if the source WAV is not Red Book (e.g. 48000 Hz)
>> > that the problem does not happen?
>> >
>>
>> No, I tested it with 44100 Hz and 48kHz. When using "faster" settings I
>> noticed corruption regardless of the samplerate.
>>
>>
>> > And the WAV you are exporting is Red Book (44100 Hz in your project
>> > rate, and "WAV (Microsoft signed 16 bit PCM)" in the Export Options)?
>> >
>>
>> I did not do anything fancy with samplerates.
>> all my tests were performed with import_samplerate = export_samplerate
> 

-- 
View this message in context: http://n2.nabble.com/Re%3A-Bug%3A-Export-as-WAV-leads-to-file-corruption-when-overwriting-existing-file-%28current-cvs-version-is-still-affected%21%29-tp1116131p1444792.html
Sent from the audacity-devel mailing list archive at Nabble.com.