Flat lining when exporting from audacity project

[steve]

I've uploaded my project file from version 1.3.11 to Minus, anyone can have a look if they'd like. In the zip file, you'll have the project as well as the first track that was corrupted.
http://min.us/mbo9Q3tP5V

The downloaded file was only 104 MB rather than the quoted 262.9 MB
I'll try downloading it again.

[Gale Andrews]

Using my workstation (win7, 1.3.14, lame 3.98.3), I can successfully create MP3s using the project recorded using the recorder machine(xp sp3, 1.3.14). Using my workstation (win7, 1.3.14, lame 3.98.3), if I go back and try to export/create MP3s using the project created when the recorder machine was running 1.3.11, the MP3s do not export correctly and flatlines just before 1:30. I've tried both from the external USB Drive and internal hard drive.
I've uploaded my project file from version 1.3.11 to Minus, anyone can have a look if they'd like. In the zip file, you'll have the project as well as the first track that was corrupted.

OK, thanks. The old Audacity bug I had in mind which could possibly have been responsible would not be in 1.3.11.

As your experiment confirms, I would doubt lame_enc.dll is responsible for what you have seen in past exports. I also doubt loss of saved data or faulty network transmission is responsible (the data is not silenced).

Please let us know if you have any more problems (using 1.3.14). If bad recorded data which gets negatived on processing is the issue, it may be possible to copy part of the track from the current project to a new project, so make a small enough project to post somewhere.

I'm not talking about a laptop battery. The CMOS battery is the little watch battery on the motherboard that keeps the clock and computer configuration in memory while the computer is off. The clock being consistently off is a major danger signal. If the battery goes far enough down, it will kill the system configs and the machine will stop dead.

A bad laptop battery can cause the system clock to be behind even with a new CMOS battery, and if the laptop battery is weak it may not charge the CMOS battery properly. I'd say you want to look first at the laptop battery and then the CMOS battery if the clock problems are not corrected ( here is some help changing the CMOS battery for anyone that needs it).

There are known problems with editing of any sort, video or audio on USB drives. They have wonderful specifications, just not all at once. They're half-duplex. They go one direction only, then they reverse and go the other way. If your software isn't aware of that, you could get holes in the work or outright failures. It's not FireWire which is full duplex. It's a very similar problem with editing over a network. If your software is not aware of network delays, collisions and retries, it fails.

I don't know if you have bad experiences to quote but I would be fairly confident in working with Audacity projects on a USB 2.0 drive. I do so myself sometimes (they are all very long projects of 3 hours or more which is why they are on an external drive). There are no playback issues. I would not recommend working with projects over a wired or wireless network unless you have gigabit ethernet.


Gale

[steve]

It downloaded (eventually) on the second attempt.
I've not heard this album in years

The Zip extracted fine and I got a full 21:26.455
Export as MP3 128 kbps CBR stereo (LAME3.98r : -m s -V 4 -q 3 -lowpass 17 -b 128)
Got the full 21:26.504 (a tiny bit longer than the original as expected)

Verdict: nothing wrong with the project (though you should leave a little bit of headroom when exporting to MP3 as some peaks after encoding are likely to be a little higher than the original.)

[ccernst]

Thanks for checking out the project for me. I think I'm just going to rework the previous albums that were giving me problems...about a dozen. I also discovered I can reduce more of the ground noise by grounding my computer chassis to a water pipe above...virtually no ground noise now. Albums now sound even better. I'm going through all of dad's old albums and converting them for him as various gifts...money is still a bit tight and this is a perfect meaningful way to give.

I can't reduce the peaks any more as I'm using line-in and the record volume slider is as low as i can go. I'll see if there are any other inputs to use. The motherboard is an old nforce2 that had a boatload of jacks and nforce control panel I think can change what different jacks do. i'll look into it.

[kozikowski]

the MP3s do not export correctly and flatlines just before 1:30.

It's not just flat-lining. It's smashing to all negative values. In effect, it's not just going silent, it's making up its own "audio" consisting of negative battery voltage. That's what got our attention.

So you only get this effect when you open a show in 1.3.14 that you made in 1.3.11.

So when the battery goes dead and the machine has been off for a while, my motherboard loses time, FSB goes to 100,

I believe you. In older motherboards, you could kill the machine or cause instability if you held that battery bus near zero for long enough.

I'm using line-in and the record volume slider is as low as i can go.

That's one of the symptoms of using Mic-In instead of stereo Line-In. We got a series of sound cards in the company that reversed the colors of the connectors. Blue was not Stereo Line-In. We created quite a bit of damage before we figured out what happened. It must be a software problem, right? Drivers, maybe?

I also have a surround sound card and they didn't even bother to color-code the connectors. They make you look it up or follow the invisible icons.

Koz

[Edgar]

I had no problems with the DL nor with exporting (using SVN HEAD as of 1Feb12) to MP3. I also had not heard this music in years and will listen to the whole thing before deleting it.

Good luck with your project--sounds like a great gift.

[ccernst]

Koz,
I first experienced the issue when my workstation was running 1.3.12 as well.

For those playing at home, I was cutting out the first 4-5 seconds or so...leaving a half second or so before the music started. Once that was cut, then I think I was putting my cursor around 7:09, selecting track start to cursor, then exporting selection.

I've tried moving to the mic-in jack and got no change in recording levels. Audacity recording level is at 0 and through nvidia volume control panel I set the line-in and mic-in levels at the bottom...still about the same recorded levels.

[Gale Andrews]

For those playing at home, I was cutting out the first 4-5 seconds or so...leaving a half second or so before the music started. Once that was cut, then I think I was putting my cursor around 7:09, selecting track start to cursor, then exporting selection.

Thanks for the steps, I can reproduce the corruption in 2.0.0 alpha on Win 7. MP3's are corrupted after 1:28, WAV's are completely corrupted.

The project audio itself can't be processed correctly; if you amplify by -2 dB, you'll notice spikes touching +/- 0. If you then open Amplify, it offers a -50 dB reduction for a new peak of +701 dB.

The only odd thing I see in the .aup is values of "-1" for "min", instead of "-1.0", but replacing "-1" with "-1.0" in the .aup doesn't help.

1.3.3 processes the project correctly, but I haven't tried later versions. I'm not surprised, because I've seen several other reports of "flatlining" similar to this on the Forum recently and I didn't think they were all inability to open the source data (though one was).

First new P2 bug after 2.0, I guess.


Gale

[steve]

I was cutting out the first 4-5 seconds or so...leaving a half second or so before the music started. Once that was cut, then I think I was putting my cursor around 7:09, selecting track start to cursor, then exporting selection.

Yes I can also reproduce the fault (Audacity 2.0.0 alpha Jan 23 2012 on Debian Linux)

[steve]

The project audio itself can't be processed correctly; if you amplify by -2 dB, you'll notice spikes touching +/- 0. If you then open Amplify, it offers a -50 dB reduction for a new peak of +701 dB.

The only odd thing I see in the .aup is values of "-1" for "min", instead of "-1.0", but replacing "-1" with "-1.0" in the .aup doesn't help.

There are some very strange sample values in the audio - hundreds of dB - which I can only assume are corrupt data.
If you remember we had a similar issue with some Nyquist effects where "NAN" values caused further data corruption in the form of -1.0 values.
See comment 5 in bug 152.

It seems better to fix by stopping rubbish in a track
being placed in all new/modified tracks, in case there is some other case we
haven't found (such as input from wrecked hardware).

I think we have found such a case.

Here is a short extract from the project:

bad-small.wav

Corrupt samples from users project

(884 Bytes) Downloaded 70 times

Notice the peaks in this file, the peak level of each of those spikes is more than 700 dB
If "dither" is set to "shaped" and you export in any integer format, there will be -1.0 flat-line and Audacity track data remains corrupted until Audacity is restarted.
This should really be P2.

I think that we must at least upgrade the bug to P3, and preferably patch up the problem to justify only P3.

Previous versions of Audacity clipped all audio data at 0 dB. We don't want this as it removes much of the benefit of working in 32 bit float (and would be a regression), but perhaps there could be a temporary fix by limiting the maximum sample value to say +50 dB.