Skip to main content
Topic: Wavpack vs FFMPEG Wavpack (Read 671 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Wavpack vs FFMPEG Wavpack

A couple of oddities I noticed:

Wavpack 5.1 as provided by upstream produces larger files (~3-4 kbps) on extra high with no extra processing in Foobar2000 vs. "Compression level 3" in  FFMPEG native, which suggests it's comparable to -hh.

When loading a file produced with "Compression level 3" from FFMPEG into Foobar2000, it says encoder profile "Normal".

I suspect that if it wasn't writing out bitstream compliant files, they wouldn't play, but then again, I think all of the codecs that I use to play back these files are based on libavcodec. :)

The VLC documentation even mentioned that the 1.0.0 release played WavPack, to the surprise of at least the person who wrote the Wiki, and that they needed to investigate _how_ it was doing it, but "probably libavcodec".

Re: Wavpack vs FFMPEG Wavpack

Reply #1
When loading a file produced with "Compression level 3" from FFMPEG into Foobar2000, it says encoder profile "Normal".
"-compression_level 3"? foobars "identify" module lies godlessly. mediainfo says Saint True.

Re: Wavpack vs FFMPEG Wavpack

Reply #2
I haven't really experimented too much with WavPack files created with FFmpeg (I only recently discovered that they had implemented encoding). The actual encoding mode used (fast, high, etc) is provided in the first block's header as "information only" and not used for decoding (because the modes are somewhat arbitrary and continuous), so it's quite possible that that information was left out and the files are still perfectly valid. I'm working on WavPack right now, and I'll take a quick look at this.

Re: Wavpack vs FFMPEG Wavpack

Reply #3
Well, one of the reasons that I took a look at WavPack was because FFMPEG supports it.

Since FFMPEG will accept FLAC input and WavPack itself won't, and FFMPEG will take a WavPack file and turn it into an Opus file, but Opusenc won't, it seems to bridge the gap nicely.

Foobar2000 makes a nice "shortcut" when you have a billion FLAC files and you're just like "UGH!", but I do not want to have to depend on Windows software or commands that are more unwieldy than FFMPEG.

In my library of about 10,000 FLACs, the file that shrunk the most under WavPack was actually Everything Counts by Depeche Mode, which fell from 876 kbps as FLAC -8 to 836 kbps as WavPack Extra High. That made me laugh. Although almost everything in that folder did unusually well.

Overall, it took my library from 913 kbps to 889 kbps.

Re: Wavpack vs FFMPEG Wavpack

Reply #4
[...] from 876 kbps as FLAC -8 to 836 kbps as WavPack Extra High. That made me laugh. [...]
~5%. good. for better compress use optimfrog. but this made you cry... :p

 

Re: Wavpack vs FFMPEG Wavpack

Reply #5
[...] from 876 kbps as FLAC -8 to 836 kbps as WavPack Extra High. That made me laugh. [...]
~5%. good. for better compress use optimfrog. but this made you cry... :p

I know that was in jest, but....

Yes, Wavpack impressed me because although I suppose it is "slower" to decode than FLAC, it achieves significantly better compression, it's open source, and from the numbers I've seen, it actually decompresses about 33% faster than ALAC (Apple Lossless).

And people can use ALAC on phones, but since it's so much less efficient at _compression_, it will take over your storage a lot faster.

I mean, I guess I'll take their word that Monkey's Audio and is lossless. 

I'd like to see who rewrote the English language for the Hydrogen Audio Wiki who thinks that 'source available" with no modification or distribution rights, and encourages violation of the GPL is "open source". That's aside from the fact that it decodes six times slower than FLAC and 3 times slower than Wavpack, and does not (apparently) do much better than Wavpack at settings you would actually use.

AFAICT, the only possible reason anyone would use MAC, OptimFROG, or Apple Lossless would be to get some data _out_ of them to put in something that's more practical and with a way better license. To that end, it's good that Rockbox devs reversed Monkey's Audio so we can get data out of it without installing the official software, and that Apple open sourced ALAC officially (after it was reversed too).

Re: Wavpack vs FFMPEG Wavpack

Reply #6
My guess was right. FFmpeg does not store the "informational" metadata in the first block to indicate the encoding mode used, so FFmpeg files will always display as "normal" even though they might not be. Not really a big deal in my opinion. If someone was really curious, one could use the wvparser utility to find out how many decorrelation terms were used.

I have come up with the approximate equivalencies between FFmpeg "compression level" and WavPack command-line parameters. Note that there is no FFmpeg equivalent for the WavPack default bahavior.

FFmpeg compression levelWavPack command-line
0 (default)-fj0
1-x
2-hx2
3-hhx3
4-hhx4
5-hhx5
6-hhx6
7-8no equivalent

Other differences I noticed:

  • FFmpeg does not store the source file's RIFF header in the WavPack file
  • FFmpeg does not always put the same number of samples in a block as regular WavPack
  • FFmpeg does not append the undecoded block checksum (new for WavPack 5)

Otherwise, the files were perfectly valid and decoded correctly.

Re: Wavpack vs FFMPEG Wavpack

Reply #7
My guess was right. FFmpeg does not store the "informational" metadata in the first block to indicate the encoding mode used, so FFmpeg files will always display as "normal" even though they might not be. Not really a big deal in my opinion. If someone was really curious, one could use the wvparser utility to find out how many decorrelation terms were used.

I have come up with the approximate equivalencies between FFmpeg "compression level" and WavPack command-line parameters. Note that there is no FFmpeg equivalent for the WavPack default bahavior.

FFmpeg compression levelWavPack command-line
0 (default)-fj0
1-x
2-hx2
3-hhx3
4-hhx4
5-hhx5
6-hhx6
7-8no equivalent

Other differences I noticed:

  • FFmpeg does not store the source file's RIFF header in the WavPack file
  • FFmpeg does not always put the same number of samples in a block as regular WavPack
  • FFmpeg does not append the undecoded block checksum (new for WavPack 5)

Otherwise, the files were perfectly valid and decoded correctly.


1. not all files are wav files with RIFF header
2. every block except last one is of same size, its just not same number as wavpack, but there is -frame_size option that can override this
3. this is very new feature

Re: Wavpack vs FFMPEG Wavpack

Reply #8
1. not all files are wav files with RIFF header
2. every block except last one is of same size, its just not same number as wavpack, but there is -frame_size option that can override this
3. this is very new feature
I'm sorry if it sounded like I was complaining about these items. I wasn't. I was simply mentioning the reasons that WavPack files encoded with FFmpeg can be slightly different in size than those encoded with the command-line encoder. I'm very happy that someone took the time and effort to create an alternative encoder.

Re: Wavpack vs FFMPEG Wavpack

Reply #9
The sample/frame mismatch kind of threw me, but I checked the audio md5 sum and it matched and the files it complains about still pass AccurateRip if they did before.

Re: Wavpack vs FFMPEG Wavpack

Reply #10
Interesting that the behavior in FFMPEG's man page does not match what happens when you actually use it. Weird, but oh well. I kind of wonder why they even write native encoders sometimes, especially when they're worse than the reference software. This is a non issue for most users with Opus because it actually makes you override it to get the experimental native one, which is worse,  but they admit the Vorbis encoder is bad and I'd wager a guess won't ever improve.

Why not just do a wrapper for wavpack and Vorbis like they already do for LAME MP3 and reference Opus?

They are already known for a lot of code that fuzz testing has uncovered a lot of problems in. Why produce more?

But I'm handwaving here.

Re: Wavpack vs FFMPEG Wavpack

Reply #11
but they admit the Vorbis encoder is bad and I'd wager a guess won't ever improve.Why not just do a wrapper for wavpack and Vorbis like they already do for LAME MP3 and reference Opus?
ffmpeg has libvorbis encoder that uses libvorbis and it is default for ogg output. At least this is how it is in builds for windows from Zeranoe.


Re: Wavpack vs FFMPEG Wavpack

Reply #13
I'm very happy that someone took the time and effort to create an alternative encoder.

Indeed. The encoding side was open source already. So not _impossible_ to convert to wavpack from flac, just annoying without FFmpeg.

But it would have (aggravatingly) required me to use proprietary software to actually play them back without libavcodec. At that point, I would have just left them all as flac -8 because while saving several GB of space with wavpack is nice, it's just not worth depending on proprietary software.

I doubt that VLC would have invested any time in making wavpack work, but I don't suppose they'll deliberately break wavpack support that they already have as a side effect of pulling in libavcodec.  :)

DeadBeeF apparently uses the libavcodec implementation to play them too.

Re: Wavpack vs FFMPEG Wavpack

Reply #14
Loreena McKennitt - An Ancient Muse - wav 576178892 bytes
        wavpack 5.0.0    /    ffmpeg 4.1.4 c:a wavpack    /    ffmpeg 4.1.4 c:a libwavpack
0/f          330335098    /    339566492    /    329708500
1/           323030862    /    320932222    /    322312848
2/h         318783220    /    317700794    /    318611470
3/hh       316940554    /    316215598    /    316730430
4/hhx2    316340902    /    315773860    /    316730430
5/hhx3    316226004    /    315715076    /    316730430
6/hhx4    315790382    /    315681978    /    316730430
7/hhx5    315733020    /    315586916    /    316730430
8/hhx6    315699134    /    315537486    /    316730430
hhx1       316541450
in mediainfo:
ffmpeg_wavpack - "format profile 4.16", not say settings.
ffmpeg_libwavpack - "format profile 4.07", say settings.
on flac -8 this album size 321178900 bytes

 
SimplePortal 1.0.0 RC1 © 2008-2019