-
Notifications
You must be signed in to change notification settings - Fork 282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flac -t shows FLAC__STREAM_DECODER_END_OF_STREAM since version 1.4.0 for some files #487
Comments
Metadata parsing became more strict in FLAC 1.4.0. I would expect these files have corrupt metadata in some way. Would it be possible to re-encode these files with FLAC 1.3.4 and see what FLAC 1.4.0 then makes of them? It could very well be FLAC 1.3.4 does pass |
Re-encoding with flac 1.3.4 works flawlessly with the following command. The re-encoded files pass the integrity check with version 1.4.x.
Here is the metadata of the re-encoded file
|
Interestingly, also version 1.4.1 can re-encode these files without any problem and the integrity check passes for the re-encoded files. |
I have created a backtrace of the point, when the error is printed:
|
That is unexpected. Would you be able to send only the first 10 kB of the file? That should be enough to analyse this and I don't think such a short part can be considered infringing on copyright. |
here they are |
Okay, I've found the issue. It wasn't at the start of the file as I suspected, but at the very end. These files have an ID3v1 tag at the end of the file. Behaviour of FLAC in this regard changed here: b288acb However, what I do not yet understand is why the encoder does not throw an error. These files are strictly speaking non-compliant FLAC files, so the encoder should throw an error too. |
Ok, so this is basically not a bug and I should fix my files. DId I understand it right, that the decoder simply stopped at the provided metadata bound before and now continues to the end of file?
You mean, the decoding part should fail for re-encode? Otherwise I do not see the encoder problem here. Is the encoder somehow still using the metadata for the length and still converting only part of the file? In addition to the analysis, I would like to stress, that these files worked perfectly fine until now. So if the re-encode will also error out, there should be a solution to to recover the musical content, e.g., by a switch to mimic the old length calculation for re-encoding. The id3v1 tag with flac files seems not too uncommon. I have around 10 different albums (from about a thousand) with this error. So maybe it would make sense to the check if the metadata is aligned with the end of stream and provide a hint to the user that is more explanatory, i.e., to say that there appears to be additional data after the stream (most probably id3v1). I am also a bit confused why playback is still working properly with libflac. This album is mixed and there is no gap or glitch when listing the fade from track 1 to 2. Is the decoder simply aborting with an error at the right point? |
Yes. The ID3v1 tag is at the very end of the file, and the decoder used data at the very start of the file to know that it was done. However, there are cases where this data at the start of the file is wrong, and before FLAC 1.4.0, this data would be skipped.
Yes
There is a way: the
On playback, errors are ignored. Only on decoding, testing or re-encoding (which is a process of which the result is generally permanent, contrary to general playback) errors are not ignored by default. |
Thx for the extensive explanation. Should I close this Ticket then or should I keep it open to track the "re-encoding should fail, too" part? |
You can keep it open. Thing that need to be done
|
Regarding
+
For future reference I utilized id3v2 0.1.12 to address the ID3 tag issue ala.
Afterwards FLAC 1.4.3 |
ID3v1 and ID3v2 are very different. The first is at the end of the track and has a small chance of misdetection. ID3v2 on the other hand is at the start of the file and has a completely different format. Anyway, detection of ID3v1 was added with #738 |
I regularly run a flac -t check for my music collection. After upgrading from version 1.3.4 to version 1.4.1 (1.4.0 is also affected) some tests fail with
FLAC__STREAM_DECODER_END_OF_STREAM
that where ok before.Only a minority of my files are affected. Most of them are still returning OK as test result. This happens for the complete Album at once, i.e., if one file on an album is affected every other file on the album is affected as well. Thus, this might has to do with specific encoders or parameters of the encoder.
I am running a Linux build using the gentoo packages of flac. Since the files have a copyright I cannot upload an afffected file here. However, I am willing to execute further tests if needed.
The text was updated successfully, but these errors were encountered: