You’ll need to open a feature request for the last part.
For the FLAC this is as explained a very special cases in ExoPlayer, all the errors are properly handled and reported to the user when there’s errors.
This one does not trigger an error, this is reported upstream, there’s not a lot I can do here, they will not accept patches to play invalid media they have made this very clear, so the fix needs to be done at low level ExoPlayer and only them can do that.
Quick succession of buffering and ready state is not a clear indicator of this very specific issue as noted the in issue on Google tracker, can be for a lot of reasons.
You can easily fix your files with “flac --preserve-modtime --verify --force”.
Won’t that fail because of the md5 mismatch? --force allows overwriting in-place but I don’t think that matters if the decoding fails due to the md5 error. I think he’d need to add --decode-through-errors as well.
flac --preserve-modtime --verify --force 1-23\ New\ Romantic\ Sailors.flac
flac 1.3.3
Copyright (C) 2000-2009 Josh Coalson, 2011-2016 Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
1-23 New Romantic Sailors.flac: Verify OK, wrote 41400849 bytes, ratio=0,995
Interesting, perhaps that has changed in the more recent flac versions. I recall re-compression failing because of mismatched md5 in 1.4.3 and 1.5.0 but I don’t have a test flac file to verify at the moment.
@655321 is correct that an extra step is needed with newer versions of flac. @Tolriq’s output shows he’s using flac 1.3.3. I’m using Arch with flac 1.5.0. This is what happens when I run the command that @Tolriq provided with no modifications:
1-23 New Romantic Sailors.flac: ERROR: MD5sum of input is different from MD5sum of output
flac decodes the old file fine and encodes a new file, but it doesn’t overwrite the old file in-place because it detects that the MD5 hashes don’t match (since the old hash was wrong in the first place for the stream that’s actually there).
--decode-through-errors does not seem to do anything to affect this, though (presumably because the problem is happening when comparing hashes after the new encode, not during the old decode). To be clear, I do still end up with the new file in a temporary location, and I can just delete the old one and rename the new one manually, so this still works as a workaround.
Good to know. I usually search for intact replacement files when I encounter files with md5 mismatch (or other errors), which is why I very rarely try to “fix” such files. My way to “fix” them is usually to open them in iZotope RX, inspect the audio visually to ensure that neither the start nor end is cut short and also that there are no gaps or loud blips in the audio and then to export it as a new flac file from there.
You may also be able to enable the internal decoder. I’ve never had an actual file from my library be corrupt, but I have had a cached file get corrupted. The internal decoder has gotten those files to play through without stopping (as does deleting the offline cache for that file and re-downloading). The same may apply for a corrupt library file.
