Skip to content
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

ID3: Consider size of extended header when reading ID3 data #631

Merged
merged 1 commit into from
Oct 1, 2023

Conversation

phw
Copy link
Collaborator

@phw phw commented Sep 28, 2023

Reading of ID3 tags with extended headers could fail, as the data being read did not consider that the extended header had already been read. This meant it would read more data then actually part of the ID3 tags, and if not enough data was available (e.g. the ID3 is located at the end of the file) it would fail.

Fixes #630

@phw phw requested a review from lazka September 28, 2023 16:50
@phw
Copy link
Collaborator Author

phw commented Sep 28, 2023

@lazka maybe it should be discussed if there is any value in mutagen supporting the extended header, maybe at least in a way that it tries to preserve it, at least those flags that make sense. Currently upon saving the extended header will be gone as it is not supported.

But this PR is purely for fixing the loading of such files, as at least this part is implemented, but was not fully working.

Copy link

@dolkow dolkow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixes the issue on my test WAV, and the original WAV with which I first noticed the problem.

Copy link
Member

@lazka lazka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@lazka
Copy link
Member

lazka commented Oct 1, 2023

@lazka maybe it should be discussed if there is any value in mutagen supporting the extended header, maybe at least in a way that it tries to preserve it, at least those flags that make sense. Currently upon saving the extended header will be gone as it is not supported.

Hm, I wouldn't try to preserve them, since they have to be kept in sync with the data and we can't just start failing on save when writing a new tag, but we could expose them on load and allow them as extra save options.

  • Tag is an update: This could be exposed and we could allow the user to set it. I don't know any software supporting this though.
  • CRC data present: We could allow expose it, and allow to write it. But it would make every write slower since we have to read back everything. Also we would need to expose the extended header size as well, so it can be checked by the user.
  • Tag restrictions: Could be a save option which makes sure all frames respect the restrictions.. but not sure there are any use cases for that.

But, I'm not sure that this is all worth it. We should at least document somewhere which parts of the spec we implement and which we don't, like footers for example.

@phw phw merged commit cc18b4b into quodlibet:main Oct 1, 2023
16 checks passed
@phw phw deleted the id3-extended-header-fix branch October 1, 2023 16:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IOError (not enough bytes) in read_full() on WAV file with extended ID3 header
3 participants