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
Hello there!
I found some issues while processing some M4A audio files, where chapter timestamps are wrong.
For reference, I compared with VLC and ffmpeg outputs (which agree) and figured the timestamps where multiplied by 1.666 in my audio files. I also noticed that there's a closed issue that seems to complain about the same (issue #451)
So that got me digging a bit on how this works, so I fired a hex viewer and found the chapters and their start points, which are encoded in 10s of microsends. The only thing that seemed off was the timestamp scaling by _timescale (here: https://github.com/quodlibet/mutagen/blob/main/mutagen/mp4/__init__.py#L1006), this is what produces the scaling factor (in my file, timescale is 600, so it is implicitely using a 1000/600 factor).
Looking at other implementations (VLC, mp4v2) I think this scaling factor is wrong and it should be removed, just divide by 1000 to scale it down to seconds).
Lemme know if you want me to send a PR. It would be good to create some example file to reproduce the issue, since the ones I've used are copyrighted and cannot be uploaded here :)
The text was updated successfully, but these errors were encountered:
Ok uploading an example.
This file has 3 chapters at 0, 10 and 20 seconds, I created it using mp4chaps, both VLC and ffmpeg properly parse these.
However when I do:
import mutagen.mp4
f = mutagen.mp4.MP4('test.m4a')
f.chapters.pprint()
Funnily enough the test file covering this (./tests/data/nero-chapters.m4b) has a timescale of 1000, so the test would not cover this. We could perhaps include the attached file, got it from zapsplat.com which has a permissive license (it is anyway not distributed and only used for testing).
Hello there!
I found some issues while processing some M4A audio files, where chapter timestamps are wrong.
For reference, I compared with VLC and ffmpeg outputs (which agree) and figured the timestamps where multiplied by 1.666 in my audio files. I also noticed that there's a closed issue that seems to complain about the same (issue #451)
So that got me digging a bit on how this works, so I fired a hex viewer and found the chapters and their start points, which are encoded in 10s of microsends. The only thing that seemed off was the timestamp scaling by _timescale (here: https://github.com/quodlibet/mutagen/blob/main/mutagen/mp4/__init__.py#L1006), this is what produces the scaling factor (in my file, timescale is 600, so it is implicitely using a 1000/600 factor).
Looking at other implementations (VLC, mp4v2) I think this scaling factor is wrong and it should be removed, just divide by 1000 to scale it down to seconds).
Lemme know if you want me to send a PR. It would be good to create some example file to reproduce the issue, since the ones I've used are copyrighted and cannot be uploaded here :)
The text was updated successfully, but these errors were encountered: