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

Processing comment field with nulls #267

Closed
bll123 opened this issue Sep 22, 2016 · 6 comments
Closed

Processing comment field with nulls #267

bll123 opened this issue Sep 22, 2016 · 6 comments
Labels
bug

Comments

@bll123
Copy link

@bll123 bll123 commented Sep 22, 2016

MP3 file with the following comment field (as reported by mutagen-inspect version 1.22 on Linux):

COMM=='\x00\x00\x00'=Track 1

On Windows with version 1.33.1 or version 1.34.1, mutagen-inspect (using python 3.4) fails to process the ID3 tags.
Output is only:
C:\Users\bll\Desktop\BallroomDJ\test.dir>"C:\python34\python.exe" "C:\python34\Scripts\mutagen-inspect" "test-files/movingon.mp3"
-- test-files/movingon.mp3

  • MPEG 1 layer 3, 192000 bps (CBR?), 44100 Hz, 2 chn, 150.05 seconds (audio/mp3)
@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Sep 22, 2016

Can you provide the file? (reiter.chrstoph@gmail.com)

@bll123

This comment has been minimized.

Copy link
Author

@bll123 bll123 commented Sep 22, 2016

@bll123

This comment has been minimized.

Copy link
Author

@bll123 bll123 commented Sep 22, 2016

Yup, upload worked this time.

@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Sep 22, 2016

Thanks!

@lazka lazka added the bug label Sep 22, 2016
@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Sep 22, 2016

bisected to 73f7bb6

@lazka

This comment has been minimized.

Copy link
Member

@lazka lazka commented Sep 23, 2016

The values are missing a BOM. We used to use the python utf-16 decoder which falls back to the system byte order (uhh.. why?) in that case. The bisected commit changed it to use the incremental decode which fails in such a case.

We should fall back to utf-16-le in case the BOM is missing. Because

  • there is a separate utf-16-be id3 encoding
  • the default encoding for Windows is utf-16-le
  • my test suite contains a few files where it's utf-16-le with missing BOM
  • the file provided here as well
@lazka lazka closed this in ef2d345 Sep 25, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.