quodlibet / mutagen

Python module for handling audio metadata

Home Page:https://mutagen.readthedocs.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bad chapter timestamps for Mp4 files

davidgfnet opened this issue · comments

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

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

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