[NIB] Writing metadata to mp4-files yields an error

[Rohbert]

Hi Mario,

With IMatch version 2025.1.12 I got an error when writing back metadata to video files (Pixel 8a). With the version before it worked. The errormessage is now: "Error. No data reference for sample description 0 for Track 1." This seems somehow familiar to me. Wasn't this problem already present in earlier versions, which you were then able to solve? Any ideas on what I could do?

Best,
Robert

[Mario]

I have no idea.
Where does this error show? Does IMatch display a dialog box? In the log file? In the ExifTool output panel? Does the file show a yellow warning icon? Where can I download a sample video that has this problem?
Pixels have many issues with metadata and file format consistency. Maybe this is just one of those issues?
I have literally nothing to work with here.

Update.

I have 3 sample videos from Pixel 8A and Pro in my library.
Write-backs to all videos work just fine, no errors or warnings reported, XMP metadata written fine.

[Rohbert]

Ok, I attached a screenshot including the dialog box IMatch displayed, and the IMatch debug report.
As I wrote before, no problems in the previous version. To test this, I changed the rating of a already saved video file and tried to write back the data - the yellow warning icon appears. I applied the update and the error occurs. What else than reporting this bug should I do?

Regards,
Robert

[Mario]

ExifTool issues the error message you quoted in your post.
When I google for this error message, I find quite a number of references. All seem to be older.
Not sure what I can do about this.
I could only post a bug report in the ExifTool forum and send Phil the video when you sent it to me. Maybe you can do that yourself, without me in middle?

[Rohbert]

Here is the link to download a video file for testing:
https://1drv.ms/v/c/4aa73129b7c60450/EXcUJ8C0PS5Ev7K7-s8f2HQBa_u0isB7jwcFRyye0-6jTw?e=h6xAQ8

In IMatch 2025.1.10 everthing was fine, now it does not work. Something has changed, either in ExifTool or in IMatch. I am not the right person to investigate this.

[axel.hennig]

I can confirm this.

Downloaded the video, imported into IMatch-testDB. Set Rating to 1 and clicked write-back. Error occurs (yellow triangle).

Attached the exiftool-output.

When googling you can find something similar in Exiftool-forum: https://exiftool.org/forum/index.php?topic=16999.0

Looks like Google did some weired stuff. Phil already suggested a solution... Does not seem to be an IMatch problem but a problem exiftool has to take care of (but the original problem seems to come from the Phone/Google).

[Mario]

Thanks for checking. I'll leave that in the good hands of Phil and the other ExifTool luminaries then.
When they have a fix for this, I will ship an ExifTool update with the next release of IMatch.

Did I mention that I hate video metadata even more as image metadata - because the tech companies give a sh*t about the crappy metadata they write to the files their devices produce. Creates no profit => not important.

[axel.hennig]

What I'm confused about is that Phil writes:

I'll patch ExifTool 13.17 to revert to the previous behaviour, even though I believe this is a bug in the way the file is written, rather than an ExifTool bug.

And I think IMatch 2025.1.12 uses ExifTool 13.17

Edit: Reading the post again, I think Phil mixed up version numbers... should (hopefully) be fixed in Exiftool versions AFTER 13.17

[Mario]

If he patches the 13.17, this modification will be in the 13.18 or whatever follows.

[Rohbert]

@axel.hennig: Thank you very much for exploring the problem!

@Mario: I understand that you hate video metadata, but for me video files are part of my content along with images and I think many users feel the same way. I also understand that this is not due to IMatch itself, but to ExifTool. But for me as a normal user it doesn't matter because I hardly have the time and resources to deal with it. Even the bug report itself cost me a bit of Sunday time that I should actually be spending with my family. In other words, I use IMatch to save time and not to solve problems with the software itself - even though I am not an inexperienced user and also code myself. Thanks for your efforts, though!

Robert

[Mario]

@axel.hennig: Thank you very much for exploring the problem!

@Mario: I understand that you hate video metadata, but for me video files are part of my content along with images and I think many users feel the same way. I also understand that this is not due to IMatch itself, but to ExifTool. But for me as a normal user it doesn't matter because I hardly have the time and resources to deal with it. Even the bug report itself cost me a bit of Sunday time that I should actually be spending with my family. In other words, I use IMatch to save time and not to solve problems with the software itself - even though I am not an inexperienced user and also code myself. Thanks for your efforts, though!

Robert

The problem is that it always boils up at my end. I have literally wasted many months of my lifetime with metadata mess created by big camera vendors and IT companies.

And I'm just one person, somehow trying to fix all the problems of all IMatch users.

I'm for sure no genius who knows everything there is about metadata standards, image formats, video formats, the ever-changing nature of the formats and metadata variations camera vendors produce. Most of this is undocumented, or vendors don't stick to standards - and IMatch users and I notice new problems only when they appear.

Sorry for your Sunday time. Much appreciated.
I've started at 7:30 this morning, now it's almost 20:00 and I still have about 20 emails to read and some potential glitches to identify before I can call it a day. Your is just one of many community posts I handled today, and a lot more emails. Busy times, as usual after a new release.

I was not informed by Adobe that they add JPXL to DNG files produced by Lightroom, breaking compatibility with WIC and LibRaw. I just got the bug reports, because IMatch failed to handle the "new" DNG files.

Who knows if and when Microsoft will update the official WIC DNG coded to support the new JPXL previews.
I've had to spend a week of my time to figure out the problem. To learn how to use and compile the rather sparsely documented Adobe DNG software development kit, and how to integrate it with LibRaw to enable IMatch users to work with this new DNG variant Adobe introduced.

When camera vendors ship new proprietary RAW variants with their cameras, breaking compatibility with Windows WIC and LibRaw, the problems are reported as IMatch bugs. No camera vendor provides info or developer programs anymore. At least Nikon has the decency to ship a WIC codec for their RAW formats. But they are the only camera vendor who does.

Users let them get away with it, instead of demanding a WIC codec that allows them to view and process files they took with the cameras they paid for.

When Apple messes up XMP face regions in their phones, writing them with a width and height of 0 or without a label, of course the problem shows up in IMatch. And I have to analyze it and figure out a work-around.

Google is apparently messing with the established MP4 container format and metadata contained within in their Pixel 8 product line, causing issues in ExifTool and who knows what else.
The error boils up on my end, and I have to spend my lifetime to figure out what makes your video files so special.
I had to google for the error message ExifTool has reported for your image in the IMatch log file and via the message box, coming to the same conclusion as @axel.henning . He just beat me to it
By @axel.henning looking into this, the analysis capacity was raised by 100%!

Phil must analyze this new variation produced by Google and add support for it to ExifTool. And we can all thank him for doing that.


I know, I know. Normal people don't know anything about all of this anymore.
And only see the effect in IMatch.
Or find out about the metadata mess other software has made in their files, and then look to IMatch and me to fix it.

I've received 3 "My metadata does not work" emails today alone. Each with file attachments or download links. And I already know that, after spending 10, 20 or 60 minutes with each case, the problem is always other software and I need to spend my time to explain the users what caused the mess and how to use the tools in IMatch to fix it. Say, one hour lost of my Sunday for this alone.

I'm just human in the end.
I do what I can, but the problem is very often the sloppy work of camera vendors and big IT companies, and that users are either unknowing or uninterested in letting them know that they should do better.

[thrinn]

By @thrinn looking into this, the analysis capacity was raised by 100%!

Thanks for the flowers - but in this case, praise goes to Axel because I was not involved in this thread

[Mario]

By @thrinn looking into this, the analysis capacity was raised by 100%!

Thanks for the flowers - but in this case, praise goes to Axel because I was not involved in this thread

Stupid me. Fixed.
Anyway, thanks for your help in many other threads.

[Rohbert]

Dear Mario,

You don't need to apologize, especially not if it's meant ironically. It's a bit strange when you set your time invested against mine, because you are the producer and I am the consumer. I understand all your points and I also know that a huge amount of effort goes into IMatch. That's why I've bought all IMatch versions since 2017, i.e. since I've known the software. I really enjoy using IMatch and appreciate your work. I mean that in the way I say it.

You certainly have a lot of work with support requests. That's why I'm trying to keep my bug report short and sweet. I think I did that in a polite way. I also didn't put any pressure or demand timely solutions. However, I was irritated by the fact that statements are doubted first, that there are no problems here, etc. You can do that when you receive an unfriendly request. But I have described exactly what the problem is and that it worked in version 1.10, but no longer after the upgrade. It didn't occur to me that a newer version of ExifTool could be to blame. I don't usually make a note of the version numbers of the libraries involved. It could have been a different execution command in IMatch. So forgive me for first contacting the author of the software I'm using.

It also irritates me a little that the problem is passed on to the user or the third-party software used. Of course you are not to be blamed in this case! However, essential functions of your software are based on this tool, and it is not unexpected to receive requests in this regard.
Imagine you buy a car, the engine stutters from one day to the next and the salesman tells you that you could ask Bosch, they make the spark plugs. And anyway, it's all annoying, all the different manufacturers of on-board electronics, brakes, tires ... - If the salesman said that it was probably Bosch and that new spark plugs would be fitted at the next inspection, then I would have no problem at all. But that's not how your statement came across, at least to me.

Have a nice evening and a less stressful week.

Robert

[Mario]

The way I see it, the problem is not me, Phil Harvey, ExifTool or the the LibRaw project.

The problem is the maker of the device you paid for and are using. Google (in your case, but also other names) is not respecting the industry standards, not caring, not documenting, making up their stuff as they go. Break things and fail fast, etc.
Giving a sh*t for standard-compliance. And then expecting all other people, applications, projects and services out there to handle this and fix what Google* has broken. Way over my pay grade.

ExifTool may have a bug. Or not handling all variants of the MP4 metadata correctly.
Or, since this seems to affect only the Google Pixel 8A (and maybe Pro), Google probably messed up?!

In the end, this lands in my lap.

As I see it, the metadata in your videos is breaking ExifTool, the gold standard in metadata management for the past 20 years. Not good, but  can happen.

I wonder what Google tells you when you contact them about this? If you can reach an actual person, and not just a chat bot. Did you?

I'm sure if the Google developers who wrote the code that causes the problems and Phil from ExifTool work together, the issue you're facing can be solved in a couple of days or weeks. I'd be happy to help when I can.

Imagine you buy a car, the engine stutters from one day to the next and the salesman tells you that you could ask Bosch, they make the spark plugs.

I did. I'm from Germany and I've started my career, many years ago, as a certified car mechanic. I happen to know quite a bit about cars. At the time, BMW and Bosch replaced the injection pump, spark plugs and fittings for my car for free.
And paid for my time on top.

This does not happen anymore these days. Consumers have become virtually powerless and the law departments in the companies have become too big.

As I tried to express above: As soon as Google and ExifTool handle this correctly, it will work in IMatch too.
There is nothing I can do about this myself.
Since you've bought a phone from Google, I assume you are eligible for support. Tell them about the issue you are facing and ask Google to contact Phil from ExifTool to sort this out.

[sinus]

Imagine you buy a car, the engine stutters from one day to the next and the salesman tells you that you could ask Bosch, they make the spark plugs. And anyway, it's all annoying, all the different manufacturers of on-board electronics, brakes, tires ... - If the salesman said that it was probably Bosch and that new spark plugs would be fitted at the next inspection, then I would have no problem at all. But that's not how your statement came across, at least to me.

Have a nice evening and a less stressful week.

Robert

I am not sure, if it make sense to take this a an example, but of course I see your point.

Yes, if I buy a new car, and it stotters, the car-company, where I bought the car, will fix it.

But if we are go to digital things in the car, it changes: When I buy a car, I read carefully the handbook (what is nowadays mostly a pdf). Then, say e.g. the "drive-assistents" explains all the behaviour of the knobs and touchscreens and so on.

Fine, but then it works in some areas not in this way, like it is written. Then go to the car-company, where you bought the car ... you will have mostly not chance.
"in the latest updates this works differently" ... "we cannot do something for this" and so on. 
This happens to me several times, the last time with a Ford, where they changed the behaviour of some points from the "speed-assistent". 

In such cases the act exactly in the same way like it is in this case from IMatch here.
IF the the car mechanic can fix it, he will, because he wants to have a satisfied user.
But if he cannot, he will say sorry, and he will say you, then you must contact Ford (in my case).
And there you have usually no chance.

I am also not sure, if this makes sense, but I think, Mario is a bit in the same boat like my scenario. He can do nothing other than refer me to another appropriate office, like e.g. Google. 

 

[Rohbert]

Mario, I don't think we're coming together here. As I have already written several times, I agree with you that the issue is not yours. I have not criticized you in this regard.
I just find it problematic that you refuse to take the view of a normal user. I don't have to apologize for buying a Google Phone. I'm also not going to turn to Google and complain that they don't adhere to the standards - if the phone works with all its features, there's no recourse.

Of course, it's very, very annoying for developers when they want to unite different manufacturers under one hood and some don't adhere to the standards. But they have to be able to deal with this, because they offer software that claims to do so.

What am I supposed to do as an IMatch user? My workflow is as it is, it used to work and now it no longer does. I have reported this, nothing more. If FUJIfilm provides a firmware update and then DxO PL can no longer open my RAWS, then I also write to DxO first. That's frustrating for DxO, but to be honest: if they were to tell me to ask Fujifilm, not our site, I would change the software. (@sinus: Ok, the example with the car wasn't quite right).

Once again, I'm not blaming you or anyone else or anything like that and I don't want to argue with you because I really like your software. But I also don't want to have to apologize for reporting a malfunction here, that's all. Do I have to think twice about reporting errors in future? Do I need to have determined the exact cause beforehand? I think not.

Best,
Robert

[Mario]

Phil fixed the Google metadata in Pixal 8A video metadata problem in ExifTool 13.18, released on February 3, just two days after I've finalized the build for IMatch 2025.1

ExifTool 13.19 was released on February 10.
I will include this version in the next release.

I could reproduce the problem reported by the OP only with the 8A video provided, not with the video files I have from the 8 Pro version or older Pixel devices. Strange.

Anyhow, ExifTool 13.19 has no issues updating XMP metadata in the file provided by the OP.

[Rohbert]

Mario, thank you very much. I really appreciate it. And maybe I was a bit thin-skinned, I'm sorry about that.

Robert