Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Create a new Tagging Standard? (Read 16290 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Create a new Tagging Standard?

Reply #50 –
It's fine with me (but I'm not somebody with special tagging needs).    Only one problem: Replaygain info doesn't get stored in the file here (just in the database). But I already told jcsston about that.

Regards,
The Link

Create a new Tagging Standard?

Reply #51 –
Quote
Quote
So please, look at the Matroska Tags Specs and tell us if there is a different standard naming convention already being used for a specific tag.

LOL .... no feedback, as usual. And afterwards they all come whining because they dont like what we did  .....

I start complaining now  . I think that it sucks that I can only insert tags with predefined names. 

Create a new Tagging Standard?

Reply #52 –
Well, you can actually enter in any tag names that you want.  The thing is that this is a list of all of the predefined names that are accepted as Matroska Tags and are required to be listable to say that a program is Matroska compliant.

However, we would really like to be able to include all commonly used tags in this list.  So, that is why we need people to list all of the tags that they use so that we can have a definitive list.  This is very important to ensure that everyone stores data the same way.  Otherwise someone can get a file and while it may have all of the data that they want, it is not listed in such a way that it will be automatically displayed.

Create a new Tagging Standard?

Reply #53 –
Pamel, thanks for pointing out this thread. I've been curious about Matroska, and couldn't quite understand what was going on. These discussions help.

I do have some feedback, yet perhaps not what you're looking for

Is Yet Another Container what we really need? Perhaps if Matroska's goals were simplified a bit, it could become a huge step forward.

Right now, Matroska defines a new way to hold both content and tags -- a new file format.

What if it were simply a new way to hold the metadata, the tags, WITHOUT any content?

What if it were not competing with existing formats, but rather supporting them all as:
* a local, universal, container for the metadata captured by the user
* source of metadata for (re)tagging any file

Just a thought. We've been discussing this idea elsewhere... a new thread has just been set up.

THANKS for all your hard work! We newbie users sure appreciate the efforts of all you experts who make this possible!

Create a new Tagging Standard?

Reply #54 –
Quote
Is Yet Another Container what we really need? Perhaps if Matroska's goals were simplified a bit, it could become a huge step forward.

matroska is nor 'yet another container format' .

With AVI being unable to cope with modern audio and video compression formats, there is a vacuum for a general use editing and storage container format to replace it.

Yes, Quicktime's MOV could have been used, but me like anybody else on Windows are just getting psycho trips if we only hear the word 'Quicktime' ...... in short, there are too many negative thoughts from many people about this container. Also, as there is no powerful opensource MOV library existing, for both content parsing and muxing, we didnt save anything by building on top of their specs, so we started with a white piece of paper.

Of course, we always knew that we arent done with just creating a nice library and specs for it. We can not expect that anybody will start implementing matroska support into his tool, unless it really became a standard. Thats why, in contrary to other existing opensource containers, we always cared a lot about making good implementations for the most common platforms, and also to make plugins for the most used apps.

After all, matroska only chance is that people can actually use it, so we have to care about that and cant rely on others. Once it reached a certain critical mass, and that happened already in the video world, you dont have to invest so much work as before because people start implementing it automatically. To give an example, Mosu was coding matroska support into mplayer, a widely used video player for Linux. The VLC people were next to follow, there is a gstreamer matroska plugin since end of last week and now recently Xine got matroska support also. Thats the way things work, and we know that.

Our next thing to focus on is a powerful, free video editor, similar to Virtualdub, but not based on VfW. The editor will, in addition to MKV of course, support MP4, Ogg Theora and even MPEG also. If it will get accepted as Vdub's successor, one day in far future, matroska will become widely available to the users. It will be their decision if they use it or not, and thats ok. And we will work hard to make it their preferred option  ....

Create a new Tagging Standard?

Reply #55 –
OK, I'll complain before the Matroska tag format is set in stone...

You've effectively referenced ReplayGain data without using the words "ReplayGain" - not helpful!

I assume track vs album is taken care of in the structure of the container itself? If not, then you need track and album for ReplayGain and peak value.

(I'm sure you've thought this through - to the point that "album" data (be it ReplayGain, or title, or whatever) needs to be available at the track level - even if I have just one track from an album, I need to know the name of the album, and the album ReplayGain. (Sorry if this isn't appropriate and has been covered a million times before - I'm sorry I've avoided looking at Matroska until now, but it seems kind of useful  ))

Consider carefully the numberical format of the ReplayGain and peak values.

Please consider the additions I suggested in the "Improving ReplayGain" thread.

Here's a pedantic point (and I'll forever be in awe if you can spot the reason it might be important, without reading an explanation anywhere  )...

It's not "The gain to apply to reach 89db SPL on playback", it's "The gain required to make the perceived loudness equivalent to 83dB SPL on playback, plus 6dB"

Any questions: I'm happy to help.

Cheers,
David.

Create a new Tagging Standard?

Reply #56 –
Quote
Is Yet Another Container what we really need? Perhaps if Matroska's goals were simplified a bit, it could become a huge step forward.

Right now, Matroska defines a new way to hold both content and tags -- a new file format.

What if it were simply a new way to hold the metadata, the tags, WITHOUT any content?

This is one of those "can't see the forest because of the trees" situations.  What people often don't realize is each time a new audio format is introduced, another container is also introduced.  MP3, MPC, AAC, Vorbis, etc all have their own container formats.  Anyone that wants to support these will have to include a container parser AND a decoder for EACH format. Oh, and as you already noticed, each system has its own way of tagging with its own specified subset of supported tags.

What Matroska does is simplify by making a single container format for everything to use. To support these files, you only need a single container parser and seeking code, plus a decoder for each format.  You can also be sure that you can use the same tags not matter what codec you use for your audio.

And yes, you could have a file with just the tags and no content.

Create a new Tagging Standard?

Reply #57 –
Quote
MP3, MPC, AAC, Vorbis, etc all have their own container formats.

Pas vrai. MP3 and MPC don't have official containers. MP3 was only meant to be multiplexed with MPEG1/2 video, not wrapped. MPC has always been containerless.

Create a new Tagging Standard?

Reply #58 –
Quote
OK, I'll complain before the Matroska tag format is set in stone...

You've effectively referenced ReplayGain data without using the words "ReplayGain" - not helpful!

Thanks, thats what we need.

Yes, ReplayGain needs to be referenced.  In fact, the ReplayGain spec needs to be linked to.  Is there any chance that if ReplayGain is improved, that the improved version will be labelled as ReplayGain2?  This is a concern as you don't want to be storing two different types of data in the same field.

Quote
I assume track vs album is taken care of in the structure of the container itself? If not, then you need track and album for ReplayGain and peak value.

Of course.    The ReplayGain data is stored as a Tag.  Tags can be applied to the whole file, albums, individual tracks, or any combination of tracks.

Quote
Consider carefully the numberical format of the ReplayGain and peak values.

Please consider the additions I suggested in the "Improving ReplayGain" thread.

With few exceptions, all of the tags are stored in UTF-8.  The Matroska project is all about bringing together standards.  Where there aren't existing ones, new ones are made.  But this is obviously a case of a pre-existing standard.  When the very knowledgable folks at HA decide on how exactly to improve ReplayGain, that is what will be used.  It is best to link directly to an existing spec.

Quote
Any questions: I'm happy to help.

Yes, any more oddities that you see, please point them out to us.  Also, what would you suggest for a quick description for the AUDIO_GAIN and AUDIO_PEAK Tags?  What you used above?  BTW, these tags may be renamed shortly to be more indicative, especially if a ReplayGain2 is planned.

Create a new Tagging Standard?

Reply #59 –
Quote
MP3 and MPC don't have official containers.

The synch headers used in these formats would nonetheless be considered containers, although rudimentary ones at best. 

This a a touch OT, but MP3 is an interesting case.  The headers used in MP3 files are certainly a type of container, and Matroska's position is to replace containers.  So, when storing MP3 in Matroska, the obvious thing would be to remove the header information as it is not technically needed.  But, the decision was made to keep it as basically no MP3 decoder is going to like being handed raw MP3 data without the headers.  Had Matroska been built 10 years ago before, stripping the headers would have been done and decoders would have been built to handle this.

Create a new Tagging Standard?

Reply #60 –
@2Bdecided:  I was just looking over the replaygain specs and I am really at a loss at how to define the storage of this information.  It is probably linked to the fact that I am really tired, but how would it be best to store this information in UTF-8?