Select-all + Export Selected produces different .wav file

[jimav]

Binary package hint: audacity

Exporting the entirety of a .wav file produces a .wav file with different contents.

This is surprising. The "Original" file was actually produced by a previous export from Audacity,
so I'm assuming there is nothing special about the format, at least nothing which Audacity does not understand.

$ audacity Original.wav
Control-A (select all of waveform)
File->Export Selection to ExportedFromAudacity.wav
File->Exit

$ cmp Original.wav ExportedFromAudacity.wav
ExportedFromAudacity.wav Original.wav differ: byte 57, line 1

(I will attach demo files)

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: audacity 1.3.12-2
ProcVersionSignature: Ubuntu 2.6.32-23.37-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-23-generic x86_64
AlsaCards:
 0 [Intel ]: HDA-Intel - HDA Intel
                       HDA Intel at 0xfbaf8000 irq 22
  1 [HDMI ]: HDA-Intel - HDA ATI HDMI
                       HDA ATI HDMI at 0xfbbfc000 irq 34
Architecture: amd64
Date: Thu Jul 22 16:44:12 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: audacity

[Richard Ash (richard-audacityteam)]

Steve:
There has been an enquiry on the help forum
http://audacityteam.org/forum/viewtopic.php?f=12&t=9429 and it appears
that 16bit uncompressed files have dithering applied on import into
Audacity (when dithering is selected in preferences for high quality
conversion). Surely that should not be the case unless the imported
audio is being resampled to a lower bit depth.

If the default sample rate is set to 16 bit, and a 16 bit audio file is
imported, then unless dither is switched off it can be seen that
Audacity changes the sample values on import.

Someone raised a similar issue on this list recently regarding dither
being applied when a track is inverted.

Martyn:
One for the 'back burner' as far as 2.0 is concerned.

Just found this in my inbox, sorry for the 6 month delay in
responding! For the record:

The dither is being applied on export (I can see that by exporting a
generated 'true' silence and then looking at the wav file in a binary
viewer). And no, that shouldn't be the case when a 16-bit internal
representation is exported to a 16-bit file.

 From looking at the code, I broke this back on 17th Sept 2006 in
revision 1.57 of Mix.cpp when I introduced all mixing in floats.

The workaround of setting the dither pref to 'None' is good, the loss
of the use of CopySamplesNoDither isn't (which did it automatically if
formats matched). The subsequent gain of being able to apply -ve dB
gain to a clipped mix is good however (I think this is a result of
that change).

The solution is not as simple as just reverting to using
CopySamplesNoDither if the input and output formats are the same,
since we'd have to re-introduce sensible clipping. Also, does float
have as many bits of integer resolution as 24-bit int? On all
platforms? If so we could keep the mixing at float and just clip and
output in CopySamplesNoDither (rarely used).

We have 'a' user who has gone on to a different app, and a sensible
workaround. And the problem is inaudible to most (all?) of our users.

But I'm not happy that I broke that and it does need addressing at
some point.

Richard:
> One for the 'back burner' as far as 2.0 is concerned.
+1
> Also, does float have as many bits of integer resolution as 24-bit int?
A 32-bit or larger float does.

> On all platforms?
On all IEEE 754 compliant hardware, which means almost anything except a Cray
supercomputer. I'm fairly certain that's anything Audacity runs on, given we
don't have any 16-bit platforms.

> If so we could keep the mixing at float and just clip and
> output in CopySamplesNoDither (rarely used).

Richard

[Gale (gale)]

Same problem applies to MP3 (but not OGG).

[James-k-crook (james-k-crook)]

No longer in wiki Release Checklist as of 29th Jan 2010.

[Gale (gale)]

Misunderstanding - bug not fixed and still valid. Was never put on Checklist
because we were at the time placing low priority bugs in "Bugzilla only" as an
experiment.

[Gale (gale)]

Gale: Promoted to P4 - A small minority of people do report this (I've seen
four reports since the bug was raised). The noise is audible - especially in
headphones- if you reimport the exported WAV and amplify it several times in
the course of editing some very quiet classical piece.

[jimav (james-avera)]

This also happens with the daily build (version 1.3.13-alpha-Jul 22 2010)

[Gale (gale)]

*** Bug 191 has been marked as a duplicate of this bug. ***

[Gale (gale)]

Release Noting it - too many people are complaining.

[Gale (gale)]

Changed title to "Exporting from integer internal formats to files in same
format or higher adds unwanted dither noise". Just about every format is
affected (including FFmpeg formats) except OGG.

[steve d (stevethefiddle-gmail)]

(In reply to comment #7)

The problem does not occur when exporting to 24-bit PCM using the "Other
uncompressed files" option. (tested with signed 24-bit WAV and signed 24-bit
AIFF).

The problem does occur with 24-bit FLAC.

Does this give a clue to how to fix the problem?

[steve d (stevethefiddle-gmail)]

(In reply to comment #8)

For clarification on my previous comment:

1) Import a 24 bit file into Audacity with the default settings (creates a
32-bit float track).

2) Export the track as a 24 bit WAV file.

The audio in the exported file is identical to the original.

[Gale (gale)]

(In reply to comment #9)
> 1) Import a 24 bit file into Audacity with the default settings (creates a
> 32-bit float track).
> 2) Export the track as a 24 bit WAV file.
> The audio in the exported file is identical to the original.
So we are downsampling, but *not* dithering?

[steve d (stevethefiddle-gmail)]

(In reply to comment #10)

> So we are downsampling, but *not* dithering?

At first I thought that Audacity may be "doing the right thing" because 24 bit
uncompressed audio could be imported and exported losslessly, but now I think
that this may be another bug.

1) Generate silence into a 32 bit float track.
2) Export the track as 24 bit integer PCM with shaped dither enabled.

The exported track *should* have dither noise, but it is actually silent.

It appears that "Other uncompressed files > 24 bit integer" is truncating
sample values and not applying dither.

I've started a forum thread with additional details:
http://forum.audacityteam.org/viewtopic.php?f=28&t=64128

[James-k-crook (james-k-crook)]

Converting from float to integer is an interesting case.

We actually should dither 32 bit float to 32 bit integer when the RMS signal is
below .004, since in that range we are effectively downsampling. We should
dither 32 bit float to 24 bit integer when the signal is below 1.0 RMS, i.e all
the time.

However, if the original signal came from a 24 bit integer source, and it has
not been modified, i.e. no effects applied, then the dither noise should be
adding to low significance bits which are zero, and so should not affect the
output. So if we test importing 24 bit to 32 bit float, then exporting to 24
bit, we should not see the dither noise.

I really think getting dither noise exactly right for float to 24 bit is
council of perfection. How many of our users are even sampling with 24 bit
accuracy? 24 bit to 16 bit matters, but I think we can shift what we are
worrying about here to P4.

The issue of applying dither when we shouldn't, or too much dither, is P3, I
agree. The issue of not applying dither when perhaps we should is far less of
a worry.

[Gale (gale)]

Command-line export "(external program)" is also affected. I tested exporting 16-bit silence to Apple Lossless and WMA Lossless.

[James-k-crook (james-k-crook)]

Focusing on the title and steps to reproduce, I contend that this is correct behaviour.

1. If rectangular dither is used on silence, 0.99 bits of noise are added, and quantization entirely eliminates the dither noise, so the silent audio is exported perfectly.
2. Whilst open, the '16bit' track is held as float values and operated on as float values. There may be an envelope, panning and gain applied, which take the intermediate data outside the values 16 bit can represent.

Just as Audacity cannot operate on Mp3 audio without round-trip losses, so too, with its current architecture, Audacity cannot operate on 16 bit without using float as an intermediate. That's an architectural choice, and a good one.

Our 16 bit format is held as float whilst in RAM. That is good design. We only pay a 'dither' tax for the extra precision on export or save. An actual 16 bit internal format would be worse, as we would instead pay a 'quantization tax' on every operation on the audio. Since an envelope or gain change IS an operation on the audio as far as the export stage is concerned, we would almost always pay the 'quantization tax' on export rather than as now the (lesser) dither tax.

Of course, just as Audacity could have been designed to allow cut and paste and stepped amplification of Mp3 audio without round trip losses, so too Audacity could have been designed to allow cut and paste of 16 bit format without round trip losses. With it's current architecture it comes very close indeed.

I'd recommend that when working in 16 bit format users select rectangular dither. That way cut and paste of 16 bit sources including pure silence are unaffected, and at the same time quantization noise on processed or generated audio is handled really well. The shaped dithers may handle the quantization noise very slightly better, but at the cost of disrupting silence.

A possible enhancement request is to recommend rectangular dither when 16 bit format is selected as the default in prefs.

[steve d (stevethefiddle-gmail)]

(In reply to James Crook from comment #14)
Discussion moved to QA mailing list: https://sourceforge.net/p/audacity/mailman/message/36288301/

[James-k-crook (james-k-crook)]

Also see wiki (link in the URL field), for proposal/discussion of planned/future dither changes.

[Erich Eickmeyer (eeickmeyer)]

Thank you for reporting this bug to Ubuntu.

Ubuntu 10.04 (lucid) reached end-of-life on May 9, 2013.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

This version of this package will receive no further updates. Please test against a currently supported version of this package and report a new bug against that version if the bug still exists.