Bug: default sample format ignored for imports

[Gale Andrews]

But if you have a 16-bit track, process it at 32-bit float then return it to the track as 32-bit float rather than 16-bit, what does the Track Info say?

That is a spurious argument because the Track Info does not show the format of the audio in the track. The Track Info only shows the "default" format for the track. For example, if you copy some 16-bit audio from a "16-bit track" and paste it into a "32-bit float track", then you have 16-bit audio data in a track that says "32-bit float" in the Track Info.

Obviously, I know that. Similarly if you have 32-bit Default Sample Format, then import an APE file the track info will say 16-bit. Save it as a project and reopen it and track info now says 32-bit float.

Adding one more confusion doesn't make everything right, we should address the track info problem IMO.

I think that where possible, files should import in their original bit-depth. Importing a 16 bit WAV file imports as 16-bit etc.
In cases where the import format is limited by the importer, then the file would import in whatever format the importer delivers. Importing an MP3 file with Lame would import as 16-bit because that is what LAME delivers.

MP3 imports currently respect the Default Sample Format. Is this about importing an Audacity-encoded MP3 where Luke M suggests the file has 16-bit values?

One behaviour I do I disagree with is that 24-bit WAV imports as 32-bit float when Default Sample Format is 24-bit. So I assume you disagree too, but for different reasons?

Do you envisage making "Store at Default Sample Format" a preference, off by default, or get rid of Default Sample Format? I think if we are going to have Default Sample Format we should respect that on import, irrespective of the file (even though there was a case OGG should have gone against that).

And I say that even though always importing a 16-bit file at 16-bit resolution would save space. Most people want to use effects, so they will be taking more space if we compel returning processed audio at 32-bit float.

"Processing" the audio is always performed as 32-bit float. This is where we should change the behaviour - when returning the processed data to the track we should NOT convert back down to integer format.

I do broadly agree, on account of the accumulated dithering. I think though that this should be an on-by-default preference rather than compulsory. I also think before we do that we must fix the track info so it behaves non-confusingly.


Gale

[steve]

MP3 imports currently respect the Default Sample Format. Is this about importing an Audacity-encoded MP3 where Luke M suggests the file has 16-bit values?

Oops, no, I meant Ogg

[steve]

Adding one more confusion doesn't make everything right, we should address the track info problem IMO.

I agree. The displayed bit-depth is meaningless and confusing so no point displaying it.

[steve]

One behaviour I do I disagree with is that 24-bit WAV imports as 32-bit float when Default Sample Format is 24-bit. So I assume you disagree too, but for different reasons?

This is where the detail is important. Converting to a higher bit-depth just pads the numbers with more zeros, making the data size larger but the numeric values are still the same, so there really is no benefit in increasing the bit-depth unless/until the data is processed in some way, and at that point it is converted to 32-bit float anyway.

[steve]

Do you envisage making "Store at Default Sample Format" a preference, off by default, or get rid of Default Sample Format?

I envisage removing the preferences and storing the data in the lowest format that can do so losslessly (except when saving a compressed copy of the project).
This is simpler, safer, quicker and avoids user mistakes. In the case of unprocessed 16-bit recordings it will halve the project size with no loss of quality. For processed recordings the project size will be the same as the current default. It also means that users will get "bit perfect" by default (which they don't currently).

[Luke M]

That is a spurious argument because the Track Info does not show the format of the audio in the track. The Track Info only shows the "default" format for the track. For example, if you copy some 16-bit audio from a "16-bit track" and paste it into a "32-bit float track", then you have 16-bit audio data in a track that says "32-bit float" in the Track Info. Similarly if you copy 32-bit float audio from a "32-bit track" and paste it into a "16-bit track", then you have 32-bit float audio data in a track that says "16-bit" in the Track Info.

I have to take your word for it, since I'm an Audacity newbie, but that is weird as heck.

I think that where possible, files should import in their original bit-depth. Importing a 16 bit WAV file imports as 16-bit etc.
In cases where the import format is limited by the importer, then the file would import in whatever format the importer delivers. Importing an MP3 file with Lame would import as 16-bit because that is what LAME delivers.

Audacity doesn't use LAME to import MP3, it uses MAD ( http://www.underbit.com/products/mad/ ) which supplies 32-bit fixed point. [Edit: Never mind, you meant OGG]

"Processing" the audio is always performed as 32-bit float. This is where we should change the behaviour - when returning the processed data to the track we should NOT convert back down to integer format.

Yes!

On Export to a 16 bit format file, 16-bit data blocks should not be dithered. Thus if the audio data has not been changed in Audacity (due to "processing"), then the output will be bit-perfect. 24-bit and 32-bit data blocks should be dithered by default.

The way it works now, Audacity actually always does a conversion to float when exporting. This is part of the "mixing" procedure, which is always done even when no mixing is required. So in order to get out the same 16-bit data you imported, you have to turn off dither in the preferences.

[kozikowski]

I miss INFO. Many video editors have an INFO service. What was that track before you messed with it?

"Oh, well! That's why its stuttering. It's in doobli-doo format. Call the studio and see if they have a copy in MPEG2."

Koz

[Gale Andrews]

"Processing" the audio is always performed as 32-bit float. This is where we should change the behaviour - when returning the processed data to the track we should NOT convert back down to integer format.

Yes!

That's if we have no Default Sample Format or turn it off by default. If we have a 16-bit Default Sample Format I would expect it to do exactly what it does now, because the main purpose of having that preference at 16-bit is disk-space saving.

On Export to a 16 bit format file, 16-bit data blocks should not be dithered. Thus if the audio data has not been changed in Audacity (due to "processing"), then the output will be bit-perfect. 24-bit and 32-bit data blocks should be dithered by default.

The way it works now, Audacity actually always does a conversion to float when exporting. This is part of the "mixing" procedure, which is always done even when no mixing is required. So in order to get out the same 16-bit data you imported, you have to turn off dither in the preferences.

Yes, I believe you're right and this is really Bug 22.

Mixing when not required seems questionable, but If you import two 16-bit files with the intention of mixing them, you probably should have to choose between dither and "bit perfection".


Gale

[steve]

the main purpose of having that preference at 16-bit is disk-space saving.

I can see how it might have been an issue a decade ago on a Windows 3.1 machine but is it really an issue today?

If the user is so desperately short of disk space that they have to constantly mix down to 16 bit (with the inevitable loss of quality with each process), then they really should upgrade their hard drive or work on smaller projects. If they are so desperately short of disk space then even allowing processed tracks to be automatically converted back to 16-bit format, they will still have to save, close and re-open their project after every couple of processes. It really does not make sense to me to limit the performance of Audacity in this way just for the sake of a few individual that insist on working on projects that are multiple hours long on ancient hardware.

[steve]

Mixing when not required seems questionable

Mixing is not in itself a problem. Mixing down to an integer format is the problem.