More > JRiver Media Center 21 for Windows
Backups and Tagging
ErikN:
Thank you for the patience and detailed responses. It gives me a pretty good idea of what to expect.
One additional question in case someone happens to know. As noted in the responses I can see that ts, mp4, avi are not internally tagged by MC. However, for ts and mp4 there is nothing that prevents internal tagging -- I could store a pdf, poetry, and a picture of my grandmother in either. It just might be in a non-standard program or box respectively. You could even put it in user data or a custom nalu of h.264 elementary streams if motivated.
So the question. Was the choice not to internally tag ts/mp4/etc. because of limited usefulness/portability outside of MC or because these file are usually big? Or, put differently, is the decision likely to change?
mwillems:
--- Quote from: ErikN on September 09, 2015, 01:11:28 pm ---Thank you for the patience and detailed responses. It gives me a pretty good idea of what to expect.
One additional question in case someone happens to know. As noted in the responses I can see that ts, mp4, avi are not internally tagged by MC. However, for ts and mp4 there is nothing that prevents internal tagging -- I could store a pdf, poetry, and a picture of my grandmother in either. It just might be in a non-standard program or box respectively. You could even put it in user data or a custom nalu of h.264 elementary streams if motivated.
So the question. Was the choice not to internally tag ts/mp4/etc. because of limited usefulness/portability outside of MC or because these file are usually big? Or, put differently, is the decision likely to change?
--- End quote ---
I can't speak for mp4 (I mentioned .mkv above, not .mp4), and I don't know for certain what the rationale is for not tagging .ts (or .mkv for that matter). I seem to recall some discussions about sidecars for .ts pointing to a desire to maintain compatibility with various hardware player boxes (i.e. improved portability/compatibility).
Yours is the first post I've seen expressing concern about internal tagging based on file size/backup consequences, so I'm not sure that's on the devs' radar (but it may be eventually as the Id project moves along). Maybe Hendrik or Matt can chime in with the rationale for writing tags to some video formats (like .wmv) but not all?
glynor:
--- Quote from: mwillems on September 09, 2015, 01:30:18 pm ---Maybe Hendrik or Matt can chime in with the rationale for writing tags to some video formats (like .wmv) but not all?
--- End quote ---
I can't speak to why, specifically, they chose to write tags to wmv. However, I can speak a bit to why they don't write tags to many video formats that do support a tagging architecture (like MKV, etc). It really comes down to this: Tagging standards. For audio file formats, there are existing, well supported standards over the tagging formats used. By this I do not mean how you technically embed the tags within the files. As you pointed out, many video containers are technically capable of having all sorts of tags and other bits of data stuffed into the container. But instead, standards around how these tags are written and read and interpreted by other applications.
Essentially, the equivalent of ID3 for video. There is no generally agreed upon standard that many applications use when deciding precisely how to store [Series] or [Description] or [MPAA Rating] within a file, or even what tags should exist and what they should be named.
This is what causes the issue mwillems mentioned about fragile support in other players (particularly hardware players). Many of them puke and die when they encounter something their simple playback code wasn't built to encounter, and they aren't built to encounter it because there is no good standard.
And, so, if you did embed them in the files, not only would you risk breaking playback on such-and-such dumbly coded player, but only MC would be able to use them. And tags embedded in the files that only MC can use are of very limited utility (since MC has a database, after all, and doesn't really even use the embedded tags except at import time). Tags are all about interchange of metadata between applications, and without an agreed upon standard, this can't effectively be done.
You could go the Apple route and just make up your own standard, but then that doesn't support interchange with anything else. The sidecars, on the other hand, are simple XML and can be parsed by simple scripts (or even by a human in a text editor).
So, in general, the sidecars are more effective due to our current lack of standards around video tagging methodology.
Hendrik:
I think the only reason we write to wmv is because we use a Microsoft reader for WMV which has a tagging interface.
Many other video containers all have their own way to store tags, and it would be a format specific implementation for each and everyone of them. Not only that, some video formats don't really allow adding tags after-the-fact, so you would somehow have to re-write the entire file to make space for tags in the right place, which is insane effort to validate that we don't break or change the remaining content of the files.
Then of course a whole bunch of video formats don't even allow tags at all, or only an extremely limited subset of pre-defined tags.
So in short, video tag support is inconsistent at best, potentially days/weeks of development effort, and generally not worth it.
ErikN:
Great responses.
In case there was any confusion, I wasn't asking for extending embedded tags to more video formats :) My hope was the opposite, that nothing changes -- except, apparently, not internally tagging wmv. I don't have many wmv and quality isn't a concern for the few I do have so I may just covert them all to mp4.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version