After 20-40 edits and project saves the sound quality of my tracks has deteriorated (on many different projects).
My procedure is to record a stereo track with voice and guitar, load this to a project, them set about adding extra tracks underneath it - essentially adding a rhythm section. Every time I do a significant edit, I save the whole project as an aup. In this process I never edit the original song, but it gets saved every time I save the project, and then reloaded again.
I was disconcerted to find recently that after many repeats of this process, the sound quality of the original song had deteriorated in two ways:
The volume was reduced
The overall sound had become fuzzy.
I find this surprising, as the project is stored digitally, so there should be no loss.
Can anyone explain this phenomenon? I can get around it (sort of) by re-loading the original stereo track from an early saved copy into the latest project, but this is not ideal.
the sound quality of the original song had deteriorated in two ways:
The volume was reduced
The “original audio” shouldn’t be touched except for any effects/processing/editing that you do.
The overall sound had become fuzzy.
Mixing is done by summation which often pushes your levels into clipping (distortion). Analog mixers have level controls for each input plus a master level control. Audacity’s mixer doesn’t have a master control.
You can reduce the individual tracks before mixing but you can also export as floating-point WAV which can go over 0dB without clipping. Then re-import the floating-point mix and Normalize (or run the Amplify effect) to bring the levels safely-down.
…Audacity uses floating-point so it can go over 0dB “internally” so if you’re not playing back at full-volume and clipping your DAC, you might not hear distortion until after you export.
I can get around it (sort of) by re-loading the original stereo track from an early saved copy into the latest project, but this is not ideal.
It’s always a good idea to save (export) a WAV file after recording, even if you don’t need it,
The “original audio” shouldn’t be touched except for any effects/processing/editing that you do.
Agreed, Doug, but the original audio is being degraded without editing - that is my problem.
Mixing is done by summation which often pushes your levels into clipping (distortion).
Agreed, however the track deteriorates without mixing. I can separate it out from the unmixed project, and listen to it on its own.
More Data:
I have found one project where I did a lot of editing, in which the (unedited) original track is not degraded, or not noticeably so. I have tried to analyse what I did differently in the projects with degradation. I think there are two possibilites:
Considerable use of effects, such as Amplify, Change Tempo, Fade In, Fade Out, Bass and Treble. Obviously, these should only alter the selected area, and are unlikely to affect my original track.
Massive use of the Undo command. Looking back through my work, I estimate that I could have clicked Undo between 500-1000 times on each of the affected projects. When I am struggling with a track, say adding a new bass G, I might perform this series of 8 commands for this one note:
Paste G from clipboard> Shift Right> Shift Left> Shift Left. Amplify-2db. Change Tempo> Generate Silence> Fade out
Having listened to this, I might decide that I don’t want G there after all, I want D instead. So I hit Undo 8 times to remove the G work from the project, and start again with D, which I might Undo also.
My Question is: What does Audacity do when you hit Undo 8 times? Does it do a perfect restore to the earlier Project from accurately saved data? Or does it ‘reconstruct’ the earlier Project using an algorithmic process, recalculating the supposedly original wave forms? If it is the second case, then you would expect 500 Undos to cause all the wave forms in the project to drift unpredictably, including ones not edited.
No. This should not be happening - at all! I have never seen any reports of similar issues. Now there have been reports where parts or all of the data have been lost in a project (and hopefully this issue will be corrected in the upcoming 3.0.0 release), but never a quality issue.
Can you provide specific steps so that others might try to replicate your issue ?
Okay, I have prepared a number of test protocols. However, I have been editing so much stuff over the last few days that I have clobbered my ears, and can’t trust them to evaluate subtle differences.
Right, I have discovered why my tracks have deteriorated after multiple edits in Audacity - it’s quite funny, really.
I didn’t have to wait for my ears to recover - I remembered the trick for comparing (almost) identical tracks using the Invert effect. And I confirmed that tracks which should be identical were not, indeed, some were startlingly different. But why, how was this possible? I tried four different testing protocols, none of which reproduced the problem, so I was forced to look back at the multiple series of project saves I did on my longest project, and I found it.
The error arises from the Gain Slider on the left of the track. This has been described before:
This is particularly problematic because you don’t realise you’ve done it. I never use the Gain slider, I use Amplify instead, so it would never occur to me to see if the slider setting had altered. So how did it get altered in my case? Easy. In an extensive edit, I will mute and unmute tracks dozens of times. If I miss the mute box by half a millimetre on one of these mouse clicks, I will move the gain slider instead - by an unpredictable amount. This destroys the balance of the Project: in my case I had reduced the gain on the lead track, so all the backing tracks were too loud, making a complete dog’s bollocks of the whole thing.
What to do about it? waxcylinder suggests disabling the sliders in your preferences, which is probably the most robust solution. An alternative would be to tighten the clickable region along the sliders so that you have to click on the line for it to take effect - allowing clicks in what looks like empty space is altogether too dangerous.
In the meantime, you could have a Macro linked to a keyboard shortcut that selects all tracks and then does a set track audio with Gain at zero.
Of course you would need to remember to run it before saving - and there could be tracks where you want the gain at a level other than zero. But if you always use amplify, this Macro option would work.
a cute idea - but sadly for me personally, not only would I have to remember to run it I’d also have to remember to reload the Macro as I trash the entire contents of my Audacity settings folder several times ever day so that I can QA test with OOTB factory settings
You could have a Windows shortcut that runs a DOS Batch file that deletes your settings folder and then makes a Macros folder and copies that Macro into the folder. That way when the settings are restored upon executing Audacity, that Macro will always be there. I can’t help with the memory thing though - I have enough trouble with my own memory
Consider that experienced Audacity users have learned to click on “white space” in the track control panel to select a track. And then they see all of that wonderful real estate right above/below/between the track and gain sliders. I wonder if that is at the root of the problem.
Sad, indeed. Your original proposal had multiple suggestions, and apart from the ideas discussed already, I also liked your ‘Visual Cue’ proposals, such as the knobs could light up when moved away from centre etc.
Surely the point is that any one of these ideas would do the trick - so how do we get a developer interested?
I have had some successes lobbying developers over the years - but it’s always very hard work and takes a long time. Part of the problem is that right now we only have three developers (plus Steve who does Nyquist plug-in development) and they are all part-time volunteers and they have loads of other stuff to do.
Plus as a volunteer open-source project we have no command-structure - so the devs can choose for themselves just what they want to work on (and conversely ignore things that they don’t want to do - the only exception being P1 bug-fixing).
