search

xiph / flac

Free Lossless Audio Codec
https://xiph.org/flac/
GNU Free Documentation License v1.3
1.58k stars 278 forks source link

Compression level mapping #669

Closed tansy closed 4 months ago

tansy commented 5 months ago

Flac client uses 'compression levels', that go from 0 to 8, unlike other compressor, that uses such aliases, and go from 1 to 9. This if confusing on at least two levels. First that fist level is 0 not 1, and least is 8 not 9, which is ergonomic issue, and second, that level '0' suggests no compression, which is not the case. So, I propose to remap them to more 'standard' convention, and set them from 1 to 9.

ktmf01 commented 5 months ago

This behaviour has been around for 20+ years. Seems like a bad idea to change it just because that looks nice or something.

Furthermore, FLAC has had a compression level 9 in the past, and it might have one in the future. There have been a few proposals to use it.

tansy commented 5 months ago

This behaviour has been around for 20+ years.

Appeal to tradition is not an argument. And it's not 'just because that looks nice or something'. It's not nice, it's ergonomic. I, and I'm not alone, do take level '0' (zero) as zero compression.

Mapping into numbered levels is a convention that also is tradition, so if you want to bring that as argument then you want to follow 'traditional' convention uset in the mapping.

My argument is not traditional but ergonomic. Hope I clarified it.

ktmf01 commented 5 months ago

It is not only an appeal to 'tradition'. Changing this would break existing scripts, invalidates documentation and needs people that are already familiar with FLAC to change what they know.

Also, note that while gzip and bzip2 indeed have compression levels from 1 to 9, lzma and xz have compression levels 0 to 9, and 0 does not mean 'no compression'. zip uses compression levels 0 to 9 where 0 indeed means no compression, but rar uses levels 0 to 5. So I am not convinced there is any convention at all.

tansy commented 5 months ago

Out of compressors you mentioned, only xz conpresses with '-0'. Zip, rar, 7zip, pigz (gzip), use '-0' as 'store'. I would say, it's xz that deviates from convention.

I get your point about scripts. Documentation though is to document features, so it's secondary, in a sense, not primary, and not source.

I still hope that there will be some users who express their opinion on it. I think it matters.

ktmf01 commented 5 months ago

Also note that the compression levels are exposed over the libFLAC API, and many projects use them too. So it is not just the man pages of the flac command that would need changing, also the front-end GUIs would need changing, home-grown applications with specific requirements would need changing etc. See for example #576 which was rejected because the changes where too extensive.

Besides, changing -0 to mean 'store' would break applications relying on having the fastest possible compression. This is especially true for environments where FLAC is not used for audio, see for example https://hydrogenaud.io/index.php/topic,123712.0.html for some details of FLACs usage on the south pole to compress telescope measurement data.

tansy commented 5 months ago

I get the point. Just one thing - that telescope data ate not sound, are they? So you cannot, even remotely, assume that their codec is not modified to adapt for their data, therefore you cannot assume they use default 'compression' levels, nor default settings in any way. It's only logical to assume they don't, and they modified and adapted the program and 'container', and settings to accommodate their needs.

ktmf01 commented 5 months ago

Actually, they are using libFLAC directly without any modifications. There is no assuming, their software is open-source: https://github.com/CMB-S4/spt3g_software/

As it turns out, FLAC not just compresses audio very well, but most signals.