Bug: default sample format ignored for imports

[steve]

Don't all 32-bit float to 16-bit downconversions have the choice of adding harmonic distortion (if not dithered) or using dither?

Yes, downconverting has quantize errors which create harmonic distortion.
Any text book on audio production will say that dither should be applied once only, after all the processing is complete and the final mixdown has been made. What they don't say is what to do if the application insists on downconverting after every process - that's something that is just "not done".

There are certainly some cases where the harmonic distortion can be shown to get worse if dither is not applied each time, but I don't know if that is always the case. What I can say with certainty is that downconversions after each process will always reduce the sound quality and the deterioration is cumulative and irreversible.

Of course one benefit of your scheme is that we don't need the incremental dither noise added with effect processing if we first upconvert 16-bit track data to 32-bit.

We don't actually need to "first upconvert". If we have integer format audio, then each sample is represented by a 16 (or 24) bit integer. When we process the audio, we apply mathematical calculations with 32-bit float precision. The result of this will always be floating point numbers (the new sample values). For example, if we multiply "integer 3" by "floating point 2.0", the result is "floating point 6.0".

THE benefit of my proposed scheme is that once the audio is imported / recorded, we never have to convert the format until we export. All other benefits derive from this.

[Gale Andrews]

Of course one benefit of your scheme is that we don't need the incremental dither noise added with effect processing if we first upconvert 16-bit track data to 32-bit.

We don't actually need to "first upconvert". If we have integer format audio, then each sample is represented by a 16 (or 24) bit integer. When we process the audio, we apply mathematical calculations with 32-bit float precision. The result of this will always be floating point numbers (the new sample values). For example, if we multiply "integer 3" by "floating point 2.0", the result is "floating point 6.0".

THE benefit of my proposed scheme is that once the audio is imported / recorded, we never have to convert the format until we export. All other benefits derive from this.

OK, so the processing is doing the de facto upconversion, no? Because if in our example we were to show the sample format stored in track 1, then after Amplify, it would change from 16-bit to 32-bit.
Is that not "converting the format before export"?

If instead of amplifying, I was to explicitly convert the 16-bit data dragged into track 1 to 32-bit float using the track dropdown menu, are those calculations different (or even potentially lossy in fringe cases), compared to performing an Amplify of 0 dB?


Gale

[steve]

OK, so the processing is doing the de facto upconversion, no?

Yes, but it is not a case of "first" convert "and then" process (2 steps). It is just "process", and "process" returns 32-bit float values (1 step)
What we do now for 16-bit tracks is: "first" process, "and then" convert to 16-bit (2 steps). That second steps is destructive (lossy) and imo totally unnecessary. It also requires a lot of extra code and associated risk of bugs.

If instead of amplifying, I was to explicitly convert the 16-bit data dragged into track 1 to 32-bit float using the track dropdown menu, are those calculations different (or even potentially lossy in fringe cases), compared to performing an Amplify of 0 dB?

Converting from 16-bit to 32-bit float is totally lossless.It does however takes a certain amount of time and CPU cycles. The time taken to convert from 16-bit to 32-bit float using the track dropdown menu is about the same as amplifying (test on long tracks).

Converting from 32-bit float to 16-bit is slower and more CPU intensive if dithered (default). It is also lossy. On a slow machine with long tracks, the extra processing time could be very significant. Processing 16-bit tracks in my tests typically take two to three time longer to process than 32-bit float tracks.

[waxcylinder]

OK so is ther a FR in here or even a bug in here? What do I do with this thread?

Peter

[steve]

I think it needs a wiki proposal, though I don't feel very motivated to write one as it is not a "glamorous" proposal and it is extremely unlikely that it will ever get beyond the proposal stage. Realistically I think that the best we can do is to encourage users to always convert imported files to 32-bit float format when they are not converted automatically.

[Gale Andrews]

I think it needs a wiki proposal, though I don't feel very motivated to write one as it is not a "glamorous" proposal and it is extremely unlikely that it will ever get beyond the proposal stage. Realistically I think that the best we can do is to encourage users to always convert imported files to 32-bit float format when they are not converted automatically.

So we never added the bug report "Default Sample Format ignored for imports" did we? I think it is an enhancement, and actually I am dubious about logging it for the reasons Steve states.

I have now noted these additional requests.

• Track info should show the format of the audio in the track, if we display the bit depth at all (2 votes). In effect I think this is already at http://bugzilla.audacityteam.org/show_bug.cgi?id=820.

• Don't convert data formats unless/until necessary. When returning the 32-bit processed data to the track we should NOT convert back down to integer format. (3 votes)
  • No preference for this behaviour (1 vote)
  • There should be a preference, retaining "Default Sample Format" (1 vote).

I think we could archive this now.


Gale

[steve]

I think it needs a wiki proposal, though I don't feel very motivated to write one ...

but I'm motivated enough to log a bug report.
Personally I think this should be a P2 issue, but currently logged as P4.
http://bugzilla.audacityteam.org/show_bug.cgi?id=1294

[Gale Andrews]

I think it needs a wiki proposal, though I don't feel very motivated to write one ...

but I'm motivated enough to log a bug report.
Personally I think this should be a P2 issue, but currently logged as P4.
http://bugzilla.audacityteam.org/show_bug.cgi?id=1294

I think P4 is accurate given (on Windows) there is not a problem with OGG (or with all FFmpeg cases) disregarding Default Sample Rate. I pointed that out in my response to your bug report. I can live with P3 if you really want to promote it, as stated in my reply.


Gale