Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Possible Encoded File Problem? (Read 5445 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Possible Encoded File Problem?

Hey just wanted to make a post about something a noticed the other day. I have my library encoded as Wavpack files (version 5.5.0). I noticed during parts of a song there are gaps of silence that aren't in the original WAV file. Weirdly enough if i convert the Wavpack file back into WAV, the gaps of silence vanish. The screenshot I uploaded shows what I mean, with the Wavpack file at the top & WAV file at the bottom.
Here's the link to the specific Wavpack file: https://mega.nz/file/EAZiHRrL#XSnOt0PR8X5GvcRVxKtimmEPr64hVLswAL7zpCkGJE8

Thanks for your time and help!  :)

Re: Possible Encoded File Problem?

Reply #1 –
Uh-oh. Looks like ffmpeg messes up here. (Tried both 5.0.1-essentials_build-www.gyan.dev of 20220408 and the 5.1 that chocolatey provides).
 
You are using audacity, and I think that uses ffmpeg - but for decoding the file and getting thumbs up, you used official WavPack?

Trying to decode your file with ffmpeg:
Code: [Select]
[wavpack @ 00000229ad5ce980] k 35287168 is too large/s speed= 214x
[wavpack @ 00000229ad5d3700] k 34112190 is too large
[wavpack @ 00000229ad5d2d00] k 35399834 is too large/s speed= 190x
[wavpack @ 00000229ad5d2d00] k 35110575 is too large
[wavpack @ 00000229ad5d3700] k 34911153 is too large
[wavpack @ 00000229ad5d2d00] k 35048486 is too large
[wavpack @ 00000229ad5d3700] k 37734884 is too large/s speed= 198x
[wavpack @ 00000229ad5d0ac0] k 37564940 is too large
[wavpack @ 00000229ad5d1bc0] k 36266347 is too large
[wavpack @ 00000229ad5d2d00] k 35653755 is too large

It is not due to using WavPack 5:
Encoding the .wav using WavPack 4.80 (at -hhx3, same setting as yours) gives a .wv file that ffmpeg also refuses:
Code: [Select]
[wavpack @ 0000020c78f14900] k 38688149 is too large/s speed= 419x
[wavpack @ 0000020c78eb2500] k 35985308 is too large
[wavpack @ 0000020c78eb13c0] k 37460491 is too large/s speed= 202x
[wavpack @ 0000020c78f14900] k 34669216 is too large
[wavpack @ 0000020c78eb2500] k 34301154 is too large
[wavpack @ 0000020c78eb13c0] k 36155081 is too large
[wavpack @ 0000020c78eb3900] k 36229978 is too large
[wavpack @ 0000020c78f14900] k 35523125 is too large/s speed= 208x
[wavpack @ 0000020c78f14900] k 34763950 is too large
[wavpack @ 0000020c78eb3900] k 34452983 is too large

Indeed, it shows up with ffmpeg-encoded WavPack files too. Encoding the .wav file with ffmpeg -compression_level 3 gives something ffmpeg cannot decode.
Code: [Select]
[wavpack @ 0000023f31122580] k 35192320 is too large/s speed= 267x
[wavpack @ 0000023f311789c0] k 37002767 is too large/s speed= 254x
[wavpack @ 0000023f311789c0] k 34381557 is too large
[wavpack @ 0000023f311789c0] k 35086266 is too large
[wavpack @ 0000023f31179c00] k 35470605 is too large
[wavpack @ 0000023f311248c0] k 33668377 is too large
[wavpack @ 0000023f31125d80] k 36266347 is too large
[wavpack @ 0000023f311789c0] k 33708828 is too large



(By the way, not sure that x3 is an efficient thing. I'm not using WavPack that much, but it looks like -x is good value for money, and those willing to wait for -x4 can be rewarded on certain material, especially high resolution. http://www.audiograaf.nl/losslesstest/Lossless%20audio%20codec%20comparison%20-%20revision%205%20-%20hires.html )

Re: Possible Encoded File Problem?

Reply #3 –
Thanks for reporting, verifying, and submitting to FFmpeg! And sorry @silver_red210 that you're having trouble!

The offending lines in FFmpeg are here. I'm not sure why that limit is there, but it shouldn't be because 0x02000000 can be exceeded in "high" and "very high" modes.

I assume this must be exceedingly rare because it's never come up before. Does this happen with any other tracks on that album?

In any event, just reencoding with the default mode should fix the issue. In this particular file -h is also okay (it was the -hh or the -x3 that pushed it over the limit). You can do this easily from the command-line:

Code: [Select]
wavpack -hy <filename>

Thanks again!

Re: Possible Encoded File Problem?

Reply #4 –
Quote from: bryant on
0x02000000 can be exceeded in "high" and "very high" modes.

ffmpeg errs out also in normal mode. wavpack -x on the .wav, and ffmpeg returns
[edit: pasted the wrong lines, -x gives only one error line:]
[wavpack @ 000002380c8c8f80] k 33585876 is too large/s speed= 294x
when using WavPack 4.80.

A WavPack 5 encode gives more error lines. Again, using wavpack -x:
[wavpack @ 000002470fd84580] k 35102634 is too large/s speed= 114x
[wavpack @ 000002470fd84580] k 34844848 is too large/s speed= 230x
[wavpack @ 000002470fd80f40] k 34092967 is too large



(PS: Also I don't need to go higher than -compression_level 2 for ffmpeg to create a .wv it cannot decode.)

Re: Possible Encoded File Problem?

Reply #5 –
Yeah, you're right! But it definitely can't be triggered in "fast" mode...   :)

I created a debug version of WavPack that displays the maximum value for that variable they're checking so I can more easily see when it's triggered. It isn't really tied to any specific mode because the different modes only differ quantitatively, not qualitatively (despite the naming). The higher the mode the more likely this happens, and -x makes it worse because it's loosely tied to how much compression is being achieved.

Re: Possible Encoded File Problem?

Reply #6 –
Sorry for hijacking your thread.

I have ~150 minute, 6 channel, 32-bit float, 48 kHz RF64 WAV file created by ffmpeg.

When I try to compress it using WavPack I get "xxx.wav is not a valid .WAV file!".
When I try to compress it using ffmpeg I get "100 buffers queued in out_0_0, something may be wrong."
When I try to play it in foobar2000 it says duration is over 1 day long.

Same file but this time exported by Audacity.

WavPack loves it.
ffmpeg same warning.
Duration in foobar2000 is correct.

ffmpeg bug?
gold plated toslink fan

Re: Possible Encoded File Problem?

Reply #7 –
Yeah, it certainly looks like FFmpeg doesn't make a proper rf64 since even their own decoder won't touch it. You say "warning", but I assume FFmpeg will not compress it at all, right? But anyway, it sounds like their parser doesn't handle rf64 files correctly even if they're okay.

One thing you could try is using the -i option in WavPack on the "bad" file. That's a lot more tolerant of things wacky in the header and just makes a good guess. It's not ideal if there's RIFF stuff at the end though.

In any event, certainly sounds like at least one FFmpeg bug. But they're very fast...there's already a working patch posted for the OP's find, although it can be years before it's gotten out to everywhere it's used.

Re: Possible Encoded File Problem?

Reply #9 –
Hey everyone. Thx for all the help & support in such a quick period of time!  Yeah this was only the song in my library that i noticed that had this issue. I'm on Debian linux and I first noticed it when i was listening to the songs through VLC. So it does make sense since a lot programs use ffmpeg to decode. Also thx for posting the ticket to ffmpeg too. You're all awesome  :D

Re: Possible Encoded File Problem?

Reply #10 –
Well thanks back for reporting it. I see you took the effort to register for the sake of it. (Still, next time please mention what application triggered it; VLC with version number and Audacity with all the details ... this time, luckily, the Audacity screenshot could be identified.)

But VLC ... folks, is there any need for a separate bug report to VLC? We know it is about to get fixed in ffmpeg, but
* VLC is such a big player, and
* Who says they will jump to the next ffmpeg version if it has no report that it is necessary?
Anyone knows their whereabouts?

Re: Possible Encoded File Problem?

Reply #11 –
Quote from: Porcus on
Well thanks back for reporting it. I see you took the effort to register for the sake of it. (Still, next time please mention what application triggered it; VLC with version number and Audacity with all the details ... this time, luckily, the Audacity screenshot could be identified.)

But VLC ... folks, is there any need for a separate bug report to VLC? We know it is about to get fixed in ffmpeg, but
* VLC is such a big player, and
* Who says they will jump to the next ffmpeg version if it has no report that it is necessary?
Anyone knows their whereabouts?
So the programs i tested were VLC (3.0.17.4), Audacity (2.4.2), & MPV (0.34.1), and they all the issue due to ffmpeg. Also thx for the link to your post of how the compression performs  :D. I didn't realize anyone did a size/speed test for the codec.

Re: Possible Encoded File Problem?

Reply #12 –
Quote from: silver_red210 on
I didn't realize anyone did a size/speed test for the codec.
http://www.audiograaf.nl/downloads.html - by @ktf here at the forum - is kinda the resource the last ten to fifteen years.

But if you see the links in strikeout at the bottom of https://wiki.hydrogenaud.io/index.php?title=Lossless_comparison#References , it was quite a sport around 2006. Especially here. Monkey's would save you drive space, but FLAC would be more battery-efficient than any other compressor, likely including general-purpose compressors like .zip (although I am not so sure about compressed file systems).
I guess WavPack would have been more popular if a "reasonable middle ground" were valued as much as winning either the size race or the speed race. But we are getting impressed by ... well, I don't know how long time it took me to realize what is the fastest encoder around (TAK at -p0) and how damn good that one is. Probably more time than it took me catching what WavPack was good for, to be honest. People judge TAK by -p4m, not by -p0.