Option to *NOT* preserve metadata when encoding mp4/m4v

Archive of historical feature requests.
Please use the GitHub link above to report issues.
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Post Reply
rachel
Novice
Posts: 71
Joined: Thu Mar 15, 2007 7:34 pm

Option to *NOT* preserve metadata when encoding mp4/m4v

Post by rachel »

Problem:

I record a bunch of stuff off-air using EyeTV. If I encode them to .mp4 or .m4v using HandBrake the metadata inserted into the file by EyeTV from the programme guide is preserved - including the thumbnail image. This sounds like a good idea, right?

Not always:

I use Plex for my media player. It seems Plex will tend to prefer metadata in the file to data that it finds in its own media lookups. This isn't ideal.

And it can be outright wrong: If for instance I want to record two (or more) consecutive programmes on EyeTV, because I can't depend on the divide between the recordings happening in the gap between them, I instead make one recording schedule based usually on the first that covers the whole period I need to record, then export sections from that for encoding with HandBrake. Therefore, and for more reasons than just this one, but this one annoys me most, the finished video can have completely inappropriate metadata; and often I know that's going to be the case beforehand.

Additionally, and beyond EyeTV, it can make renaming of videos problematic: You rename the file, and the file *name* is what's significant to you, and whatever media organisation software you're using, but the metadata *inside* it is still wrong, and still picked up upon by various software.

One way of addressing this is just to output to MKV instead of MP4. It's a fine balance, frankly, and I might just end up doing that again. Some reasons why not: Now the AppleTV3 is out, it's reasonable to try to produce a file from handbrake that's suitable for both Plex and for AppleTV3 and newer iOS devices, even though I don't have such devices right now. Also, it being easier to, if one has to, convert an MP4 to MKV (using mkvtoolnix) than to go in the opposite direction.

Also I'm not sure why MKV output doesn't contain that metadata: is it a shortcoming in the format, or in handbrake for choosing not to do it? If the latter, then that shortcoming could be fixed in future, thus making MKV output no longer an option to resolve this problem.

So, I'd just like a little checkbox - not sure whether in prefs or in the options for a given file - that allows the user to choose whether to preserve such metadata or not.
Deleted User 11865

Re: Option to *NOT* preserve metadata when encoding mp4/m4v

Post by Deleted User 11865 »

It's not a shortcoming of the format - it's just that HandBrake doesn't write much metadata to MKV.

I'm not opposed to that feature, though since it requires GUI changes, it wouldn't be at the top of my priority list.

In the meantime, I believe Subler can also remove metadata from MP4 files.
rachel
Novice
Posts: 71
Joined: Thu Mar 15, 2007 7:34 pm

Re: Option to *NOT* preserve metadata when encoding mp4/m4v

Post by rachel »

forced to workaround, and still wanting .mp4 output from handbrake, and what with having zero luck with subler in the past; what I'd probably do is use mkvtoolnix on the source *before* transcoding with handbrake, to strip the metadata. Except it only works for HD recordings which are exported without transcoding as .mp4 - but not for SD recordings which are MPEG2 which mkvtoolnix doesn't handle :-(

It is, of course, a whole extra step I'm just usually too lazy for; so checkbox pretty-please. :-) My thought is it might have similar GUI logic to the "large file" option for MP4 encodes at present, and in terms of the GUI could be implemented the same way, in the same place. The choice would then also be stored in saved presets, which - although I'd probably always have it off (ie: *don't* preserve metadata - the checkbox should be positive even though the default reflecting current behaviour is on) - seems more sensible to me than having it in application preferences.
Post Reply