-
Notifications
You must be signed in to change notification settings - Fork 170
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
Inaccurate Meta Data for m4a media format #337
Comments
Thanks! Can you provide a small sample file that reproduces the problem please? |
Please check attached file. It shows below information with my code. Thanks!
At 2023-08-03 06:56:01, "Drew Noakes" ***@***.***> wrote:
Thanks! Can you provide a small sample file that reproduces the problem please?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Thanks but unfortunately it seems files attached to emails are not added to the issue. You'll need to attach it via the web UI. |
ring.m4a.pdf |
@xianglongcheng here's the output I get for your file:
Is the issue you're describing with this field?
The file here is actually an MP4 file. The M4A extension exists to help identify audio-only MP4 files. How would you suggest we identify the expected file type extension in this case? That directory is currently only populated using information from the header of the file (magic bytes at the start). |
From the output, it already shows "[QuickTime File Type - 0x0001] Major Brand = M4A", so I think it would be more accurate to show the expected extension as "m4a".
As I'm not familiar with the mp4 file format, the request might cause too much coding or even possible issue. If that's the case, we can just keep current output which is already great and easy to read.
Thanks!
|
The library populates the file type directory based only on the header. Later, the file is identified as M4A once the actual M data is parsed, but we don't go back and modify the other directory. Today, you could use the tag you identified to understand when you have an M4A and update accordingly. Longer term this would be a candidate for another issue we have that tracks consolidating data across multiple tags (which I can't find easily now in my phone). |
Sure. Thanks! |
FWIW; the MIME content type here is wrong either way. It lists |
I believe that the [QuickTime Movie Header - 0x0005] TrackId is mislabeled. According to exiftools, that value corresponds to the Media Time Scale. The [QuickTime Track Header - 0x0005] TrackId value is correct |
It seems it will parse the metadata of m4a(audio format) as mp4 video format. I'm using below code to work around this, but if this could be fixed it would be pefect. Thanks very much!
The text was updated successfully, but these errors were encountered: