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: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF (Read 1868 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

The new preview add "FLAC decoder: log premature EOF, mark partially encoded files as bad even if they don't appear corrupted otherwise".
Mostly all of FLAs that I played triggers a popup error, but passed the integrity test and seems to play fine so at first doesn't seem too critical, but I wonder what I can do to correct it and the real severity.

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #1 –
I have the same problem. To avoid the popup window, deactivate "Show error messages popups" in Advanced Preferences. Most of my FLAC's are affected, the few not affected show a temporary popup window with progress bar. Can't identify the popup window, because its very short living (more a flicker).

https://hydrogenaud.io/index.php/topic,124137.msg1027421.html#msg1027421

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #2 –
Yes, in 2.1 preview 2023-05-17 on playback this feature gives out false alarm.

BTW, FLACs with premature EOF was always perfectly detected on verification with Integrity Verifier as "Reported length is inaccurate".
Here is example of file with real premature EOF - https://www.dropbox.com/s/n9awti95o8kt88v/TRUNCATED%20%40%203m%2031s.flac?dl=1

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #3 –
Quote from: Bogozo on
Yes, in 2.1 preview 2023-05-17 on playback this feature gives out false alarm.

BTW, FLACs with premature EOF was always perfectly detected on verification with Integrity Verifier as "Reported length is inaccurate".
Here is example of file with real premature EOF - https://www.dropbox.com/s/n9awti95o8kt88v/TRUNCATED%20%40%203m%2031s.flac?dl=1

That's a relief. None of the files that trigger the pop-up gives that error.

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #4 –
Quote from: Bogozo on
BTW, FLACs with premature EOF was always perfectly detected on verification with Integrity Verifier as "Reported length is inaccurate".
My experience was that Integrity Verifier caught it, but bitcompare didn't. It could sometimes return that files decoded fine, because the decoder didn't check (only the integrity verifier would).

If the change has made decoder more zealous than Integrity Verifier is, then ... hm, Peter needs to scratch his head over something.

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #5 –
This is happening to me as well. It tends to occur when I have clicked to a different place in a song and then played to the end.
Think millionaire, but with cannons.

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #6 –
Thanks for reporting, fixed version will be out tomorrow.

In meanwhile, this is a clear bug in libFLAC, or at least bad documentation.
The documentation doesn't say that I should be expecting a writeCallback from INSIDE FLAC__stream_decoder_seek_absolute(), only mentions different behavior of next writeCallback. My code assumed writeCallback to happen from inside next FLAC__stream_decoder_process_single(), not from FLAC__stream_decoder_seek_absolute() directly.
I think this should be specifically documented.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #7 –
Quote from: Peter on
In meanwhile, this is a clear bug in libFLAC, or at least bad documentation.
The documentation doesn't say that I should be expecting a writeCallback from INSIDE FLAC__stream_decoder_seek_absolute(), only mentions different behavior of next writeCallback. My code assumed writeCallback to happen from inside next FLAC__stream_decoder_process_single(), not from FLAC__stream_decoder_seek_absolute() directly.
I think this should be specifically documented.

Something for @ktf

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #8 –
As far as I am aware, this is not a recent change. It seems to me libFLAC has had this behaviour for years. That means I can't change it (or I will break other implementations), so I'll update the documentation.

Probably change this to something like this?
Quote
Flush the input, seek to an absolute sample and return the (partial) block in which the requested sample lies through the write callback, starting at the requested sample. In effect, this works like FLAC__stream_decoder_process_single, but at the block in which the requested sample lies, and with all preceding samples removed from the output buffer. The client must support seeking the input or this function will fail and return false. Furthermore, if the decoder state is FLAC__STREAM_DECODER_SEEK_ERROR, then the decoder must be flushed with FLAC__stream_decoder_flush() or reset with FLAC__stream_decoder_reset() before decoding can continue.
Music: sounds arranged such that they construct feelings.

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #9 –
Thanks for looking at it.
The behavior must be old, it just caught me off-guard - everything seemed OK in my code, yet setting decode position counter *after* successful seek was doing the wrong thing.
Microsoft Windows: We can't script here, this is bat country.

Re: foobar2000 v2.1 preview 2023-05-17 and FLAC premature EOF

Reply #10 –
Quote from: Peter on
Thanks for reporting, fixed version will be out tomorrow.

In meanwhile, this is a clear bug in libFLAC, or at least bad documentation.
The documentation doesn't say that I should be expecting a writeCallback from INSIDE FLAC__stream_decoder_seek_absolute(), only mentions different behavior of next writeCallback. My code assumed writeCallback to happen from inside next FLAC__stream_decoder_process_single(), not from FLAC__stream_decoder_seek_absolute() directly.
I think this should be specifically documented.

the 2023-05-22 preview released today is with this fix? thanks