Expand Audacity

[klimmbimm]

I checked out the latest Beta development source code from http://audacity.googlecode.com/svn/audacity-src/trunk/ (current HEAD revision: 11297) and ported my changes to the code.
Regrettably this didn't solve my problem.
I am still experiencing weird behavior if I save a (wave) file under its own file name. Mostly the saved file has the same length as its preceding version but it is 100% silence. Sometimes small pieces of sound are still in it. And often it is completely messed, which means: If the wave file contained the alphabet and was saved (and after that is not entirely empty), it will sound like this: "abcdecdecde" or similar.

Could it be, that the saving process is interrupted by any code? (But if so, why this problem won't appear when saving under a different file name?)
I am stumped again and looking forward to your help.

I attached all my changed files (based on revision 11297 of the Audacity trunk).

[Edgar]

I checked out the latest Beta development source code
I am still experiencing weird behavior if I save a (wave) file under its own file name.

Could it be, that the saving process is interrupted by any code?

To answer that final question, you will need to do a bit of detective work. If the problem occurs often enough try this...
After you save a file under its own file name, and before you exit Audacity, listen to the newly saved file in some other app. You will not be able to open it in Audacity unless you change its on-disk name first. If the file is hosed, listen to the track in Audacity to insure that what is on disk differs from what is in the Audacity track. This will confirm if the disk save was the problem or if the track became corrupt before export. I know this is a real hassle!

First, do as many tests as possible using the regular (Unicode Release) build of SVN HEAD--see if you can replicate this bad behavior on code which does NOT contain your new code. I am a bit hazy on the specifics (maybe someone else will chip in...) but I seem to recall a recently fixed bug which caused a similar problem when saving to an existing filename. If you can repro it without your code Team Audacity needs to look further into the problem.

Second, good editing practice would suggest never overwriting a file--always do "incremental" saves*. Until you have listened to a song on a CD (never rely only on hard drive storage) keep at least a few of the most recent files of the song. If it were me, I would never have it hard-coded to save with the same name, I would generate a timestamp-based unique number and append it to the current filename (stripping an old one if it exists), I can give you code which does most of this.

*searching the forum for "incremental" gives lots of good info on the specifics of incremental backup:
http://forum.audacityteam.org/search.ph ... ncremental

with these two being Steve's & my take:
http://forum.audacityteam.org/viewtopic ... al#p153945
http://forum.audacityteam.org/viewtopic ... al#p147468
(the details are part way through the reply in each case.

[Edgar]

I DLed your code and will try to get some time to see if I can repro your problem. Do you have any clue if song length is critical? Are you working in stereo or mono?
After importing your WAV, what is the Project Rate (left-most item on the Selection toolbar)?

pr.png (2.61 KiB) Viewed 1007 times

My plan is to create a few waves by recording a series of digits (s1-100.wav, s1-300.wav, s1-500.wav , m1-100.wav, m1-300.wav, m1-500.wav etc.) so I will have some audio which is very easily checked for glitches. Of course, using standard editing good practice, I will burn these to CD and make a spare copy on a different drive before running any tests <grin> !

[klimmbimm]

Do you have any clue if song length is critical?

I don't think so. My wave-files are between about 1 and 60 seconds long. It is the same problem with the longer and the shorter ones.

Are you working in stereo or mono?
After importing your WAV, what is the Project Rate (left-most item on the Selection toolbar)?

I am working on mono files only.
At the moment the project rate is 48000 Hz, because the existing files have these characteristics (screenshot from VLC player):


The problem seems to disappear if I switch the import preferences to:
"Make a copy of uncompressed audio files before editing (safer)"

The problem here is, that playback isn't fluid anymore, but often dramatically hanging.

I'll keep trying fixing and will inform you about my results...

EDIT: I tested Audacity on several PCs with the "copy of uncompressed files"-option. Only on one computer the playback makes problems, but the saving-and-get-an-emtpy-file issue stays away.
So I decided to to let the matter rest for now.

[Edgar]

So I decided to to let the matter rest for now.

The faster/safer distinction is interesting but probably out of my depth to resolve. I always use "safer". At least you have a handle on the the problem and a work-around now.

[waxcylinder]

Topic moved from "Adding Features To Audacity" to the "Audio Processing" section.

WC