Re: Stopping Foobar2000 transcoding lossy to lossless
Reply #16 – 2022-11-12 19:10:38
There is a slightly puzzling behaviour to this. With -b999, the bit rate is high enough for this particular file not to have any loss. Therefore,The case of super high bitrates generating lossless files is something I considered quite a bit (certainly more than its rarity would justify). The reason the encoder displays “lossless” is because it just encoded the whole file without a single sample being “lossy” and it keeps track of that. But, there’s currently no way to store that information in the header, so the file will always wavpack -b999 harpe.wav is lossless for this particular file, and reports so when it concludes encoding. That is what the documentation says too: "If the track can be losslessly compressed without exceeding the specified bitrate, then it will be and WavPack will report the compression as lossless." But wvunpack -ss reports it as hybrid lossy, because it sees that it was encoded in hybrid mode and it finds no .wvc. Forcing a correction file with -cb999, it does indeed create it. But it contains no audio: deleting the .wvc and bit-comparing to the original, it is identical. But the .wv files are not the same, so the encoder does make a difference. An alternative would be to generate an ordinary .wv file and report it as modalities: lossless, high, extra-1, b-999 (or just "b" or "as hybrid"). I have a hunch that "would be" is a "could have been". appear as lossy (because it will always be hybrid mode...they’re different) and only by decoding the whole file is it possible to know it was actually lossless. If you create a correction file you’ll get counter-intuitive results like this (as you saw): david@david-HP-Laptop-15-bs1xx:~/WavPack$ ls -l 24bit.wv* -rw-rw-r-- 1 david david 2912902 Nov 12 10:05 24bit.wv -rw-rw-r-- 1 david david 8400 Nov 12 10:05 24bit.wvc david@david-HP-Laptop-15-bs1xx:~/WavPack$ cli/wvunpack -vm 24bit.wv WVUNPACK Hybrid Lossless Audio Decompressor linux-gnu Version 5.5.2 Copyright (c) 1998 - 2022 David Bryant. All Rights Reserved. original md5: d526d5fb2682675c713be47c62e40341 unpacked md5: d526d5fb2682675c713be47c62e40341 verified 24bit.wv (+.wvc) in 0.33 secs (lossless, 44.80%) david@david-HP-Laptop-15-bs1xx:~/WavPack$ cli/wvunpack -vmi 24bit.wv WVUNPACK Hybrid Lossless Audio Decompressor linux-gnu Version 5.5.2 Copyright (c) 1998 - 2022 David Bryant. All Rights Reserved. original md5: d526d5fb2682675c713be47c62e40341 unpacked md5: d526d5fb2682675c713be47c62e40341 verified 24bit.wv in 0.25 secs (lossy, 776 kbps) I could store a flag at the end to indicate this (or rewrite the header with a new flag), and I thought of deleting the correction file in this case (which might confuse the user or an application invoking WavPack), but in the end decided that this edge-case is rare enough that it’s not worth worrying about. This may be the first time it’s come up in almost 20 years since WavPack 4! As for the difference between the WavPack files themselves when creating the correction file, that’s sort of superficial. They both could have correction files, but the dynamic noise shaping works better without the correction file requirement and so you get different results. Killing DNS with -s0 should make the files identical whether a correction is created or not, and it’s also why it's a good idea to not create a correction file if you’re planning to delete it anyway. What’s funny though is sometimes I want to get around the “can’t transcode lossy to lossless” warning (probably for testing) and so use this trick. It really shouldn’t even allow going to a higher lossy bitrate, but that sounds a little too nanny-state, even for me. But I do agree that Foobar2000 should at least warn about transcoding WavPack lossy to lossless.