You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've found that scanning my Flac library there are some albums that fail with audio_metadata. Even though these files pass a 'flac -t FILE' they fail to extract with audio_metadata.
I've found that some of these files fail because of a ZERO size in a block, which is caught and triggers an exception.
While this is probably wanted behaviour for the STREAMINFO block, it seems a bit over zealous for blocks like, PADDING and SEEKTABLE.
So rather than call it a bug, I'll ask for a feature change. It requires a 1 (or2) line change in flac.py.
E.g. (Where flay.py in Downloads is the GitHub version)
[2041]$ diff flac.py ~/Downloads/flac.py
456,457c456,457
< if ( block_size == 0 ) and ( block_type == FLACMetadataBlockType.STREAMINFO ) :
< raise FormatError(f"FLAC metadata block {block_type}; size must be greater than 0.")
---
> if block_size == 0:
> raise FormatError("FLAC metadata block size must be greater than 0.")
The text was updated successfully, but these errors were encountered:
I've found that scanning my Flac library there are some albums that fail with audio_metadata. Even though these files pass a 'flac -t FILE' they fail to extract with audio_metadata.
I've found that some of these files fail because of a ZERO size in a block, which is caught and triggers an exception.
While this is probably wanted behaviour for the STREAMINFO block, it seems a bit over zealous for blocks like, PADDING and SEEKTABLE.
So rather than call it a bug, I'll ask for a feature change. It requires a 1 (or2) line change in flac.py.
E.g. (Where flay.py in Downloads is the GitHub version)
The text was updated successfully, but these errors were encountered: