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: Issue with the new libFLAC 1.4.1 ? (Read 3332 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Issue with the new libFLAC 1.4.1 ?

Hi,

I'm no expert. I've been using the Foobar2000 1.5.3 till yesterday without any issues. I updated to the latest stable 1.6.13 today and was playing through foobar WASAPI output 3.4 (I understand it isnt needn't in the new version as the exclusive mode is already supported in-app). I listened to many albums with bit depth and sample rates varying from 16 bit 44.1 Khz, 24 bit 48 Khz, 24 bit 88.2 Khz and 24 bit 192 Khz without any issues as usual until I queued up one particular FLAC 24 bit 48 Khz Track attached in the link. It plays as it should for the most part. But, it produces a small skip at 2:14 , 2:40,2:45 and at lot many places past that. These skips happen particularly in this track at the above mentioned timelines. I vividly remember the same issue didn't occur when I played the same track on Foobar version 1.5.3. So, I thought there might be a problem with the WASAPI output plugin and tried to output through non-exclusive Default : Primary Sound Driver and the skips happened even with that. So, I tried playing the same file track using a different application (MPC-HC non-exclusive mode) there was no skip to my surprise. Then I copied the same track to a different computer with different hardware and installed the latest stable foobar2000 and played the same track. same issue occurred at the same timeline no matter how many times I play.

I read the changelog of 1.6.13 and found that the FLAC decoder component got updated to 1.4.1. I downgraded from 1.6.13 to 1.6.12, NO SKIPS ON TRACK AND PLAYS AS IT SHOULD.

The skip is not happening in no other track that I have tested so far in 1.6.13 with varying bit depths and sample rates.

Is this an issue with with libFLAC 1.4.1 or why is this happening ?

sticking to 1.6.12 until then.

I'm not the owner of this track. Please dont circulate and kindly use it for testing purposes only.

Google Drive Link to the track

https://drive.google.com/file/d/1n7eBhBQkxTGe8481KVeY5bOoBm1ATNOR/view?usp=sharing

Re: Issue with the new libFLAC 1.4.1 ?

Reply #1 –
The file cannot be opened in Adobe Audition 1.5 either, and if I use foo_verifier to scan the file in foobar2000 1.6.12, it also says the file is corrupted.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #2 –
The file is corrupted, that is for sure. But different FLAC versions handle this kind of corruption differently.

And so do different foobar2000's. 1.6.12 with foo_verifier gives the following error message:
Code: [Select]
Warning: Reported length is inaccurate : 4:33.228750 vs 4:33.237333 decoded
Error: Nonsensical most significant bits - the file is corrupted
Error: MD5 mismatch
while 1.6.13 returns:
Code: [Select]
Warning: Reported length is inaccurate : 4:33.228750 vs 4:33.237333 decoded
Error: Corrupted FLAC stream
Error: MD5 mismatch


And checking with flac -t also confirms that that 1.3.x and 1.4.x treat this sort of corruption different, where 1.4.x "finds" more errors. There have been changes to 1.4.x yes, and various ways of handling errors have been discussed around, see https://hydrogenaud.io/index.php/topic,122094 and
https://github.com/xiph/flac/issues/464

edit: also, the bug report at https://sourceforge.net/p/flac/bugs/440/ indicates that some 1.3 version was too forgiving in some ways

There will always be this discussion on what a decoder/player shall do to corrupted files; try to jump past the error? Try to mute "from last known good to next known good"? Sometimes this leads to that consequence, blah blah blah.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #3 –
Sorry.

Can you please try to re-download the same file again ? I'm able to download from the same location and play it. I can upload to another cloud storage if you want to. if its corrupted, why am I able to play it ?

Re: Issue with the new libFLAC 1.4.1 ?

Reply #4 –
I get it. The source file is corrupted and the different FLAC handlers handle corruption different. I'll use the verifier component to check the file integrity first.

Thanks.

Quote from: Porcus on
The file is corrupted, that is for sure. But different FLAC versions handle this kind of corruption differently.

And so do different foobar2000's. 1.6.12 with foo_verifier gives the following error message:
Code: [Select]
Warning: Reported length is inaccurate : 4:33.228750 vs 4:33.237333 decoded
Error: Nonsensical most significant bits - the file is corrupted
Error: MD5 mismatch
while 1.6.13 returns:
Code: [Select]
Warning: Reported length is inaccurate : 4:33.228750 vs 4:33.237333 decoded
Error: Corrupted FLAC stream
Error: MD5 mismatch


And checking with flac -t also confirms that that 1.3.x and 1.4.x treat this sort of corruption different, where 1.4.x "finds" more errors. There have been changes to 1.4.x yes, and various ways of handling errors have been discussed around, see https://hydrogenaud.io/index.php/topic,122094 and
https://github.com/xiph/flac/issues/464

edit: also, the bug report at https://sourceforge.net/p/flac/bugs/440/ indicates that some 1.3 version was too forgiving in some ways

There will always be this discussion on what a decoder/player shall do to corrupted files; try to jump past the error? Try to mute "from last known good to next known good"? Sometimes this leads to that consequence, blah blah blah.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #5 –
Audition 1.5 immediately crashes by merely selecting the corrupted flac in file browser without even opening it. MPC-HC and Audacity just play the file as if there is no problem at all. SoX shows no error as well.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #6 –
Seems like this thread should be in FLAC subforum instead of foobar2000 subforum.
Also, we probably need @ktf to clarify what actually is happening with this file.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #7 –
You can see what happens by opening Audacity and checking for peaks. See the screenshot below

X

I conjecture this FLAC file was at some point directly exported from a DAW without checking for peaks. This is the responsibility of the tool (in this case probably a DAW) using libFLAC, see here

Quote
Each sample should be a signed integer, right-justified to the resolution set by FLAC__stream_encoder_set_bits_per_sample(). For example, if the resolution is 16 bits per sample, the samples should all be in the range [-32768,32767].

As you can see the file contains audio samples that exceed the valid range. This means this file is invalid.

FLAC 1.4.0 changed behavior of both encoder and decoder to actively check for these problems, because it could result in problems further downstream: applications using libFLAC expect samples to be bounded, but that isn't the case with these files.
Music: sounds arranged such that they construct feelings.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #8 –
With the update to foobar2000 v1.6.13 I stumbled upon one album that I no longer can play and I had no issue with before.
1.6.12 with foo_verifier did not find any issues with the files.
The issue turned out to be connected to the embedded artwork which is 19 MB in size (when I removed the cover, the files played OK).
FLAC has the limit of 16 MB for covers, and I'm not sure how I embedded a bigger cover, yet these files were opening prior to 1.6.13 with no issues.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #9 –
Quote from: Planaria on
The issue turned out to be connected to the embedded artwork which is 19 MB in size (when I removed the cover, the files played OK).
So, you can't play the files at all?
Music: sounds arranged such that they construct feelings.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #11 –
foobar2000 1.6.12 and MediaInfo say the file bitrate is 1511kbps while SoX reports 1.59Mbps, all higher than the format's uncompressed audio bitrate. Removing the picture with "Optimize file layout + minimize file size" in foobar2000 1.6.12 reduces the file size from 58.5MB to 55.4MB but the displayed bitrate remains unchanged. Re-compressing the file without picture file size dropped to 39.5MB and 1078kbps with level 5 compression.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #13 –
Concerning @Planaria's file, I am not sure if the error handling is the most graceful all over.

* Is there any reason for fb2k to refuse this file altogether? Reminder that it will usually play corrupted files even if it screams corruption. But if this is some kind of protection against a malicious file ...

* ... then, well - if applications need to watch their handling of files like this: does flac.exe -d work as expected?
It throws thousands of *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC and *** Got error code 1:FLAC__STREAM_DECODER_ERROR_STATUS_BAD_HEADER.
@ktf, you probably know if this is all good. If it is not "as expected", then well, maybe have a look into it even if it doesn't look outright worrisome.
Also got a single *** Got error code 3:FLAC__STREAM_DECODER_ERROR_STATUS_UNPARSEABLE_STREAM in between those, and then finally a suggestion to use metaflac ... and new metaflac cannot tell, but old does indeed say reference libFLAC 1.3.3 20190804. Deliberate change?

* ffmpeg also gives the error message "Correcting truncated metadata picture size from 3211544 to 19988760". But since the file is malformed, you cannot expect everything to agree on "what corruption to report".

* But Mp3tag's error message "cannot be opened for writing" might not be the best. (Tried to copy tagset and write it back. The problem is not that the file cannot be opened for writing, the problem is that I tried to write something that should not be written to it, and that is not the same.)

Re: Issue with the new libFLAC 1.4.1 ?

Reply #14 –
Oh wait, more here:

* Made two copies, (1) removed picture with Mp3tag and (2) removed picture with fb2k 1.6.12. Now fb2k v2 shouts Corrupted FLAC stream, and shows wrong bitrate - but plays it. And metaflac 1.4.1 returns vendor string.

* metaflac 1.4.1 cannot, however --sort-padding or --merge-padding.
The metadata to be written does not conform to the FLAC metadata
specifications.

* metaflac 1.4.1 cannot even --remove-all. The metadata "to be written" does not conform ...  hmwell.
But metaflac 1.3.4 --remove-all pretends like all is well. It isn't. So at least 1.4.1 gives an error message when it cannot do what you ask it to.

* Cut metadata with Mp3tag. Pasted it back. No cigar. So Mp3tag copies and writes metadata it cannot read.

* But ... cut metadata with Mp3tag and tried to paste it into an .ogg: Mp3tag errs out with "cannot be opened for writing."

* Actually, just cut metadata with Mp3tag and ... fb2k still reports corrupted and wrong duration.


Also, metaflac gives this error message
The FLAC file could not be opened.  Most likely the file does not exist
or is not readable.
... when the file is played by fb2k. "not readable" ... could very well have warned "or in use".

Re: Issue with the new libFLAC 1.4.1 ?

Reply #15 –
If I run flac -tF on @Planaria 's file I get a lot of errors but the MD5sum checks out. So, libFLAC is able to decode this file correctly. I've tested on FLAC 1.3.3, 1.3.4 and 1.4.1, same results.

Where you can see a change is on re-encoding. FLAC 1.3.3 and FLAC 1.3.4 happy reencode the (faulty) file, while FLAC 1.4.1 throws a new error: FLAC__STREAM_DECODER_ERROR_STATUS_BAD_METADATA It is very well possible this error is not yet handled by foobar2000.
Music: sounds arranged such that they construct feelings.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #16 –
Ah, right, library API is obscure to the commons.  So, sticking to the exe:
* flac.exe version 1.3.4 will happily decode and re-encode without (and of course with) -F, and will re-encode to "the same faulty file".
Not optimal, so behaviour changed:
* flac.exe version 1.4.1 will throw error decoding, but will decode with -dF (this is good) - but it will also refuse re-encoding even with -F.

By comparison, for a .flac file with OK metadata but a corruption in the middle of the audio:
* re-encoding without -F will abort (but leave the partial file)
* re-encoding with -F will go on until "wrote xx bytes, ratio=yy".

One can certainly argue that it would be more consistent to treat the faulty-metadata file as close to the faulty-audio file as possible, i.e. by dropping the invalid block (that is the picture!) and writing the rest?

Re: Issue with the new libFLAC 1.4.1 ?

Reply #17 –
Quote from: Porcus on
One can certainly argue that it would be more consistent to treat the faulty-metadata file as close to the faulty-audio file as possible, i.e. by dropping the invalid block (that is the picture!) and writing the rest?
Yes, that would be better. However, this is not entirely possible. When a metadata block is faulty, it is not possible to find the next one. This is because, contrary to FLAC audio frames, FLAC metadata blocks have no sync code, no CRCs and no other 'sanity checks'. It is possible to salvage metadata blocks preceding the faulty block, but it is not possible to salvage metadata blocks that follow it.

Someone could file a github issue for this. For now, I would like to focus on further hardening libFLAC against security issues before attempting to improve handling of corrupt files (as this is generally difficult without introducing security issues). Last time I tried improving handling of corrupt files, I accidentally introduced a major bug, see here. Of course, anyone is welcome to contribute.
Music: sounds arranged such that they construct feelings.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #18 –
Hello,
I have noticed a similar problem. It seems to be related to the new version of flac. The file plays normally, but foobar2000 v1.6.13 reports an error using the foo_verifier component.

Code: [Select]
1  Name: Desert Rose (Melodic Club Mix Radio Edit); Status: Failed: Corrupted FLAC stream; Warnings: <none>; MD5: 9F26CABA4BE5772F75F25D06F2583321 (OK); CRC32: 750621B1

The file is encoded in FLAC1.3.3 with Exact Audio copy and foobar2000 v1.6.12 does not report any errors.

Code: [Select]
1  Name: Desert Rose (Melodic Club Mix Radio Edit); Status: OK; Warnings: <none>; MD5: 9F26CABA4BE5772F75F25D06F2583321 (OK); CRC32: 750621B1

I used flac frontent to decode the file. With FLAC 1.3.4 I have a wav file  while with FLAC 1.4.2 it dropped such a message

Code: [Select]
01 Desert Rose (Melodic Club Mix Radio Edit).flac: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
Below link for the file
https://www.dropbox.com/s/mxxaxl2mdndvb5b/01%20Desert%20Rose%20%28Melodic%20Club%20Mix%20Radio%20Edit%29.flac?dl=1

Re: Issue with the new libFLAC 1.4.1 ?

Reply #20 –
Quote from: DJ Graco on
Hello,
I have noticed a similar problem. It seems to be related to the new version of flac. The file plays normally, but foobar2000 v1.6.13 reports an error using the foo_verifier component.
This file has an ID3v1 tag at the end. See also this issue.
Music: sounds arranged such that they construct feelings.

Re: Issue with the new libFLAC 1.4.1 ?

Reply #22 –
Quote from: ktf on
Quote from: DJ Graco on
Hello,
I have noticed a similar problem. It seems to be related to the new version of flac. The file plays normally, but foobar2000 v1.6.13 reports an error using the foo_verifier component.
This file has an ID3v1 tag at the end. See also this issue.
@DJ Graco 's file is no longer available, and I don't remember if I checked whether Mp3tag was able to detect that tag, but it does detect and can remove other EAC-generated ID3 tags.

Hopefully that is a less involved procedure than re-encoding.