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

Bad chapter timestamps for Mp4 files #639

Open
davidgfnet opened this issue Jan 30, 2024 · 2 comments
Open

Bad chapter timestamps for Mp4 files #639

davidgfnet opened this issue Jan 30, 2024 · 2 comments

Comments

@davidgfnet
Copy link

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 :)

@davidgfnet
Copy link
Author

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()

I get: 'chapters=0:00:00 Chapter 1\n 0:00:05.555556 Chapter 2\n 0:00:11.111111 Chapter 3'

Which is clearly wrong :( I will send PR

test.m4a.zip

davidgfnet added a commit to davidgfnet/mutagen that referenced this issue Jan 31, 2024
This should fix issue quodlibet#639 and get rid of other similar issues.
@davidgfnet
Copy link
Author

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).

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

No branches or pull requests

1 participant