about 1 in 10 or 15 files will result in dropout or corruption of the normalized file, the original file remains ok.
for example after the normalization, the last 30 seconds or so of only the right channel will look strange and on playback it will completely drop out.
sorry i didn’t provide enough information. all the recording is being done externally on a portable recorder then imported into audacity for processing.
internal processing is set to 32 bit float default.
One possibility is that there could be some data corruption in the audio file.
Recent versions of Audacity are protected against creating illegal samples (where the sample value is not a number) but this does not mean that a file that does contain one or more invalid sample values will work correctly.
A simple test for whether this is the problem is to either apply the Amplify effect, or “Tracks > Mix and Render” to the file. If these exhibit the same problem as Normalize then there is probably an invalid sample value in the original recording.
If you still have the original file, please try this test and let me know how it goes.
For playback, no processing is done, so it is easy to just skip over a sample that makes no sense, but when processing it’s different - for example, how do you amplify (multiply the value of) a sample whose numerical value that is not a number? Audacity reaches that sample and does not know what to do, so it returns silence from that point on.
It may show up if you enable “View menu > Show Clipping” and then zoom in on the area where it was turning to silence. If you can delete the problem samples then the rest of the file will probably be OK.
Is it possible to upload one or two of the source recordings that cause an issue somewhere for us to see? You could use dropbox or http://www.sendspace.com or http://minus.com/ .
Probably we don’t need the whole file in the case where the last 30 seconds is corrupted, just (say) the last minute.
Messages you send don’t appear in “sent” for a short while.
I have normalized the file to -1 dB then rendered it and exported it on Windows 7. No corruption.
Are you sure this is the original file you imported into Audacity - your recorder records in FLAC? If so, are you importing the FLAC file with the FLAC importer or libsndfile? Look at Help > Show Log which will list the importer used. The default on Linux is to use libsndfile.
If you are using libsndfile, are you copying in the file or reading it directly? If you do not see that asked as a question when you import, please see the Import / Export Preferences for your copy in setting.
Thanks, I’ve got the file, but I can’t find any problem with it either. It works perfectly here (on Linux).
Could you try closing Audacity and relaunching it, then download that FLAC file from your link (so that you have exactly the same file that we have), then import it into Audacity and try Normalizing it. Does the problem still occur?
On what basis did you suspect a memory problem? It is quite possible Audacity became unable to write to the temp directory - maybe even due to lack of space. If so, Help > Show Log would have showed that. If you still have Audacity open, any error messages will still be there.
Were you using an external disk for the temp directory? Was there any permissions problem with writing there?
We had a RAM processing feature until the current 2.0.2 release but had to remove it for now as it tended to cause Audacity to crash.
You can still use a software ramdisk and set that as your Audacity temp folder.