Audacity Forum

I have been using Audacity 1.3.12 on and off for about a year now mainly to only view files. Lately I expanded its use and noticed that after cutting chunks out from other files that the saved samples differed from the originals, although being displayed graphically as roughly the same but not identical.

Actually that's what triggered my quest because of the slight graphical difference, I then discovered that the samples were in fact considerably altered in the sense that no numerical matching could be done.

So I decided to simplify and loaded some samples, then immediately selected the whole set and exported the selection. Indeed the sample numerical values were entirely altered such that a binary search in the "copy" could not find a sequence of 16 bytes in the original in the copy.

To my mind this is tantamount to a bug although I think its due to Audacity's penchant for working with floating point samples i.e. the conversion between normal 2's complement wav samples. I would think that such a conversion should not produce such radically changed sample values, but I tried it with a couple of other randomly selected 16byte sequences and they all failed. Obviously the smaller you make the sequence the more chance you would have of a false match.

I don't know this is very shocking to me... can anyone throw some light on this because it means that editing with Audacity will alter your samples without cause. Pretty horrific.

P.S. for finding the bytes I used both XVI32 and HxD

If you want total accuracy, use 32-bit float format files throughout.
Down-sampling from 32-bit float to an integer format will introduce numerical differences - this is normal and intentional.
The numerical differences may appear to be a lot, but in terms of the sound it is a very tiny difference.
It would normally be expected that Audacity is used for editing and processing audio, in which case the numerical differences caused by down-sampling to 16-bit are insignificant compared to the changes made through the editing and processing.

See here for a more in-depth explanation: http://en.wikipedia.org/wiki/Dither

Hi Steve, thanks for your reply basically confirming what I thought.

Regarding dither, there was no sample rate conversion going on which is where the options for dither appear. For sample resolution (number of bits) the point of dither is to amelioration over straight truncation. There appears to be no option to control this and according to your post this dither must be the cause of the sample values varying as I can't see simply integer to float and back to integer causing that large a variance.

However I do believe that this is a distortion being applied. If e.g. the original samples were 16/24 bits which almost all sound cards generate and consume then the upscale to 32bits and the subsequent descale with dither would add distortion i.e. by any reasonable thought the altering would not add any additional musical information to the samples quite the reverse. I agree that any such distortion would be minute. However if this was repeated done then the dither on dither would grow would it not?

I think users should be made stringently aware of these points and perhaps the default format should not be 32 bit float. Additionally this effectively doubles disc requirements. Thus I am saddened to know that all my recordings to date have been distorted by unrequired dither especially my DAT digital transfers. I am of course aware that for heavy sample processing and mixing the float format is superior but for what I think most people use it for which would be sampling and light cut and pasting the fixed formats may better preserve their samples.

This comes up regularly any time somebody tries to use Audacity as a WAV editor. It's not. It's an Editorial Production Environment Manager. That's why you can't Save a sound file. Did you wonder about that? You have to Export one with the suggestion that Exporting is doing extra work to present a stand-alone file.

Somebody many pages back determined a way to set the preferences so Audacity doesn't try to "help you," but I don't remember the spells. I'm reasonably certain it wasn't as simple as setting everything to 44100, 16-bit, Stereo, although it would seem like it should be. You also need to remember to turn dithering off, etc.

This is the mild version of the problem. Audacity is not an MP3 editor, either, and that's a lot easier to create damage. Audacity will double the compression damage.

Koz

Wow koz!

Mayhaps if it comes up regularly it should be fixed by advising people in Big Bold Type that it is an "Editorial Production Environment Manager" rather than "The Free, Cross-Platform Sound Editor" blazoned on http://audacityteam.org/ (also Recorder added in the link title).

Forgive me for being an ignorant pleeb.

The Developers and the Forum Elves have had some spirited discussions about the presentation of Audacity.

Koz

jackobyDawg wrote:there was no sample rate conversion going on

Yes there was - as you say later on in your post, Audacity works in 32-bit float format, so unless you export in 32-bit float format there will be downsampling from 32-bit float to 16-bit (or 24-bit) integer. (Note that when exporting to 24-bit integer the dither noise is massively smaller than when downsampling to 16-bit, and since there are currently no sound cards capable of full 24-bit accuracy the dither noise will not be significant at all).

jackobyDawg wrote:However I do believe that this is a distortion being applied.

As we're talking about such precise issues we should be precise about the descriptions. It's not "distortion" that's added, it's "noise".

jackobyDawg wrote:However if this was repeated done then the dither on dither would grow would it not?

Yes it does. That's why dither should only be done at the end of the job.
Record, import -> process and edit, -> mix it all down, -> export with dither, end.
If it is necessary to export files and re-import them for further work, and you want pristine, pro quality, the intermediate export should be in 32-bit float format and with the same sample rate as is being used in the project. (There will be similar issues of minute but incremental quality loss by repeatedly changing the sampling rate).

jackobyDawg wrote:I think users should be made stringently aware of these points and perhaps the default format should not be 32 bit float.

I think there's more pressing issues that users should be made stringently aware of, such as "Don't Delete the _data Folder", but despite multiple pop-up messages and dire warnings you'd be amazed at how many people do delete the _data folder and then wonder why there's no data in their project.

As you say, most users just do a simple bit of recording and/or editing, then export, and that's it. In such cases, the addition of properly shaped noise at -82 dB is not going to be a big deal, especially as in most cases it will improve the sound quality.

In that "little bit of editing", most users will apply amplification, and probably fade-in / fade-out effects. Immediately they do that, their pure integer sample values are no longer pure integer values. If processing was done at 16 bit (so dithering was not necessary), then amplify and fade would need to round each sample value to the nearest 16-bit value, and this would create more damage to the sound than the dither. If you listen very carefully to a fade-to-silence in 16-bit that has not been dithered, it sounds horrible with massive distortion (quantize artefacts) as the level gets to around -70 dB, whereas with dither it fades gracefully into a very low level hiss, but the actual musical sound is still present for about an extra 10 dB.

There are a few, very specific cases where it is better to not use dither.
1) If the export format is 32-bit float (Audacity does not use dither in this case)
2) If the import/recording bit formats is the same or lower than the export format and ONLY simple editing (cut, delete, trim, paste) is done to the audio (no fades, no processing at all), then it is better to turn off dither (Edit menu > Preferences > Quality).

As for dire warnings to novice users - if we can get the message across that MP3 is inferior sound quality than WAV, then we'll be winning (spread the word )

I don't see how reducing the number of bits in a sample can be "Sample rate conversion"?

The key operative word here is "rate". In usual parlance rate equates to sampling frequency not the bit quantization of the signal.

jackobyDawg wrote:I don't see how reducing the number of bits in a sample can be "Sample rate conversion"?

Who said it was?

Let me read my last post again.....

"(There will be similar issues of minute but incremental quality loss by repeatedly changing the sampling rate)"
No, I definitely didn't say that reducing the number of bits is "Sample Rate Conversion".
Is that unclear?
What I'm meaning to say here is;
Just as there are minute but incremental quality losses by repeatedly changing the bit format (bit-depth), so too there are minute but incremental quality losses by repeatedly changing the sample rate.

Is that clearer?

You said it was Sir:

jackobyDawg wrote:there was no sample rate conversion going on


Yes there was - a

I hope that's abundantly clear as the muddied waters.

I guess I came to the wrong place to ask my question.