Wishlist in terms of supported ID3v2.4 frames

Any ideas about how to improve MediaMonkey? Let us know!

Moderator: Gurus

Posts: 13
Joined: Sat Jan 27, 2007 9:29 am

Post by stankovic »


Try Mp3Tag or foobar: it will be an easy thing to copy data from one tag to another.

(MP3Tag is not the same like MP3 Tag Clinic)
Posts: 35
Joined: Mon Apr 23, 2007 7:01 pm

Post by gk »

Thanks for the info.

I use Mp3-Tag Studio for general tag manipulation - it seems generally faster and more powerful tha mp3Tag or mp3Tag Clinic or anything else I've found.

Yes, I have found that I can copy my TIT1 data (using Mp3-Tag Studio) to 'Original Artist' (TOPE) field, or 'Album Artist' (TPE2), or COMMENT tags, which MM can read/write.

In my case, the TPE2 field would do the trick - but it seems to be the only field that will work since my requirements are:
1. Field must be read/writeable
2. Field must display in column view (not via 'properties' dialog)
3. Field must be able to SORT the display / playlist since I am entering ordered data of 'original recording date' in format:
YYYY.MM.DD - <location of recording ... etc.>

(This deviates from the id3 spec for formatting of TRDA, which is YYYY/MM/DD-HH:MM . I have never found any mp3 manager that makes the TRDA field easily accessible)

I really enjoy being able to chronologically sort an entire artists work and get a better sense of their artistic development, etc.

It is a little scary how limited MM is in terms of which editable tags can be displayed as columns. What if I decided I wanted to be able to sort on additional fields and didn't want to overwrite 'Custom 1' (COMM), etc.

I like MM but if I switch from iTunes to MM, I feel like I'd be moving to a platform that is already stretched to its limit, without much headroom in terms of customization (albiet more than iTunes has!)

There really needs to be a truly customizable mp3 manager that works like any decent database application and gives you full access to ALL available id3 fields in columnar, sortable queries of the database.
Posts: 65
Joined: Fri Feb 02, 2007 8:07 am

Post by mattisse »

Totally agree with MCSmarties initial posting. You did a great research job!

Devs please, please consider implementing ID3 support as MCSmarties describes.

What I'd also love to see is the support of:

- TRCK (Track) in the form Track#/Total # of Tracks, e.g. "4/9". It's declared in the ID3 specs and would really help filtering complete and incomplete albums.
- TPOS (Position in Set). The disc# was already introduced in MM3. Please support the corresponding ID3 tag too. Preferably also in a form like "1/2".
- TSST (Set Subtitle). This tag would be very valuable to me for storing disc names. Example: "Stadium Arcadium" by the Red Hot Chili Peppers. Disc 1 is subtitled "Jupiter", disc 2 is called "Mars".
Posts: 6316
Joined: Fri May 21, 2004 5:44 am
Location: Sweden

Post by Bex »

Yes, especially subtitle would be really helpful. I hate when i must use the album name to indicate the subtitle of a disc in a two disc album. It's the same album and it should have the exactly same name in the album field.
Advanced Duplicate Find & Fix Find More From Same - Custom Search. | Transfer PlayStat & Copy-Paste Tags/AlbumArt between any tracks.
Tagging Inconsistencies Do you think you have your tags in order? Think again...
Play History & Stats Node Like having your Last-FM account stored locally, but more advanced.
Case & Leading Zero Fixer Works on filenames too!

All My Scripts
Posts: 13
Joined: Sat Jan 27, 2007 9:29 am

Post by stankovic »

stankovic wrote:Supporting more native fields of the id3-standard and writing/reading the TXXX-frame would increase the interoperability between several programs that already do that: Godfather, Mp3Tag, foobar...

But that would be only the first step: what about other tag standards (vorbis comment, ape ...) wich doesn't have predefined so many field or not the same fields? There are three solutions:

1. You write non-defined fields in database only (Like Monkey does)

2. You write a tag wich begins with name of the application (Like Helium, JRiver MC)

But i hope that everybody can see that the most elegant solution is

3. the solution Mp3tag, foobar ... choosed: if an tag is not predefined it is written as txxx-frame (mp3) or the frame name is the same as the name of the field (ape, vorbis comment)
As i know all tag standards (ID3v2, Ape, Vorbis Comment, Wma, MP4) gives the opportunity to create any (self defined) tag so that each information could be stored as a tag in the file. I think such an excellent program like MediaMonkey wich claims to be a tagging and musicmanagement tool should support that: each need would be satisfied!

The question is just how to implement such a feature in the existing Ui. My idea is following:

1) A big part of the predefined Tags are present in the tag editor

2) In the preferences we have the opportunity to define a mapping to those fields of the other tag standards wich are not predefined just by writing a name for it (Subtitle = Subtitle or Subtitle = Sub Title). All other tag standards uses the field name as name of the frame. A better example: If i map publisher to "label" it would be written "organization" as frame for oggfiles because it is predefined so and for those standards wich has no predefination "Label" would be the frame name.

The predefined ID3 Tags then would then be mapped to other tag standards

Last but not least:

3) An extra tab in the style of MP3tag, Foobar or Winamps OGG file info editor (take a look to see what i mean) where we can create our own tags or fields

I am eager to hear of the developer if that could be the future of Media Monkey somedays.
Posts: 76
Joined: Sat Jul 21, 2007 4:38 am
Location: Switzerland

Post by Anamon »

I'd like to add a wish of my own here: do NOT add support for the playcount tag, or at least make it possible to deactivate it, and have it deactivated by default.

The PCNT field is very disputed, and rightly so: it is not meta information, and therefore shouldn't be part of the tags.

For only one example of what problems this might cause, imagine file organizing or file sharing software. Using the PCNT field would change the file and therefore its hashes and checksums, even if the file has not been changed, only listened to!
If everybody used players that update the PCNT field in the tags, it would be nearly impossible to find such tracks in P2P networks like eMule or Bit Torrent, as everybody would have a different file depending on how often it has been listened to. Backup software might go berzerk because it backs up all the music files that have been listened to since the last backup, not only changed ones. Et cetera, et cetera.

These are the dangers when the separation between file meta data and usage data is ignored!

The 3 additions / improvements that I find the most important / urgent are the above mentioned support for the "total tracks" and "total discs" field, the correction of where album artists are saved, and one thing MCSmarties has actually taken into account but not explicitly stated: the implementation of the "Encoded by" field in addition to the "Encoder" field already supported.
Posts: 248
Joined: Tue Dec 06, 2005 8:01 pm

Post by MCSmarties »

Anamon: An interesting thought re: file sharing. However, I *think* that most if not all file sharing applications are aware of metadata and routinely disregard that information when calculating checksums. I know Shareaza does.

eg, AFAIK it works like this:
- Users A, B and C share the same song but tagged differently (one person's "Hard Rock" is another person's "Arena Rock" and the third person's "Rock", for example)
- When sharing, the P2P app calculates a hash WITHOUT using metadata
- User D searches for the file and will get 3 hits (since A,B,C have the same *audio* data)
- User D downloads the file. It will include the metadata as downloaded from whoever happens to be supplying that particular data chunk (so D could end up with "Hard Rock", "Arena Rock" or "Rock" depending on whether the chunk with the metadata was supplied by A,B or C)
- User D shares the file further, labeled again with a hash that ignores the metadata.
Posts: 29
Joined: Wed Feb 28, 2007 5:47 pm

Post by dsavereide »

He absolutely right about that. First of all, don't confuse metadata like genre with usage data like play count. Metadata needs to be saved with the track, otherwise maintaining and transfering it would be a nightmare.

The metadata is fairly stable, usage data updates constantly. Backup programs should not need to be aware of the data it's backing up... this is genric activity and the same programs back up countless types of files. Nor would this be a desirable thing in most cases. If you spend a few hours going through all your tracks and updating the genres and other metadata, do you really want your backup program to see that as no change? So if you have to recover you just lost all of your updating?

Stable metadata belongs with the files. Constantly changing usage data should be mainained by the program that uses it. It's user and application specific, not track specific.
Posts: 5537
Joined: Tue Sep 06, 2005 11:01 pm

Post by Teknojnky »

Personally, I would _WANT_ play counts stored in the file tags, because that information is PORTABLE, not buried into each individual program.

But I agree it should be optional what tags are stored where.
Posts: 76
Joined: Sat Jul 21, 2007 4:38 am
Location: Switzerland

Post by Anamon »

It's definitely also a personal decision. I guess an option where each user can choose for him-/herself would be the best solution for such tags.

The technically "correct" way would be to not store such tags in the file, because as dsavereide said, the tags are metadata related to the piece of music they are associated with, therefore they should only contain data related to the music. Fields like "Playcount", "Last Played" and even "Rating" (these are the ones I'm aware of at the moment) are data about a specific listener.

I personally do not care much about automatic backups or possible problems with file indexing/sharing software due to such tags. But I still would like to keep that data out of my files, because I just want to keep them "clean" and free from data I feel doesn't belong there. I do not want to copy over such data when I give a track to a friend. And I am saving some of my music on a media storage server - playcounts stored in the file are then meaningless because all the listeners increase the same counters.
Even though the "rating" field has the same issues, this is a field I would rather have in the tags. It is a rather consistent thing I set for each track, and the playlists I create are heavily influenced by these values. That's why I would also like to have them available when I'm not using MM3. The data is stored in the wrong place, but in this specific case I'd decide for comfort against tidiness correctness.

In any case, MM3 seems to have a new option to block certain ID3-tags, and there would always be the possibility to use MM3-scripts or 3rd-party software to wipe a large selection of MP3 files from specific ID3v2 frames, should it be specifically needed.

Many words, a simple statement: I think this is one of the things that should really be left to the user to decide.
Posts: 21
Joined: Tue Jul 18, 2006 3:18 pm

Post by studley »

Teknojnky wrote:Personally, I would _WANT_ play counts stored in the file tags, because that information is PORTABLE, not buried into each individual program.

But I agree it should be optional what tags are stored where.
I agree with you. I'd love to be able to take it with me

Is ID3v2.4 back on the table now that you have finished the BIG release?

Cheers, David

New Field "Album Subtitle"

Post by Gipfelstuermer68 »

It would be nice to have an additional field to mark an album like "Remastered", "Reissue 2016", "Extended Version", "Japan Edition" .....

So I would call this field ALBUM_SUB_TITLE
Posts: 30
Joined: Sun Dec 13, 2009 6:19 pm

Is the display of subtitles on MMW and MMA possible?

Post by gipfelstürmer_68 »

It would be nice to have an additional field to mark an album like "Remastered", "Reissue 2016", "Extended Version", "Japan Edition" .....

So I would call this field ALBUM_SUBTITLE.

This new field could be used creating directories like this:

\Musik\<Album Interpret>\($if(<Datum (original)>,<Datum (original)>,<Jahr>)) $If(<ALBUM_SUBTITLE>, <Album> (<ALBUM_SUBTITLE>))\<Album>)\$If(<Disk#>, CD <Disk#>)\<Song#:2> - $If(<Interpret>=<Album Interpret>,,<Interpret> - )<Titel>
Posts: 13797
Joined: Tue Jun 10, 2003 7:21 pm
Location: Serbia

Re: Wishlist in terms of supported ID3v2.4 frames

Post by Peke »

MM5 should be more flexible, but additional fields are user preference.

I for example ALBUM_SUBTITLE would consider more for TV Series/Movies where link to external subtitle or even subtitle itself would be stored.

Custom Fields and its naming for user purpose would be more useful, even they are just database wise.
Best regards,
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to add SCREENSHOTS to forum
Posts: 48728
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Re: Wishlist in terms of supported ID3v2.4 frames

Post by Lowlander »

It would seem that ALBUM_SUBTITLE is a standard music tag that may not be commonly used in the mainstream, but nonetheless a useful tag for serious taggers. MediaMonkey should by default include more of these types of less know, but standard tags as that greatly improves MediaMonkeys tagging credentials, but more importantly would make MediaMonkey far more useful for more people.

The benefit of this would extend in that other functions like AutoPlaylist and Auto-Organizing would also benefit from this available information.
Lowlander (MediaMonkey user since 2003)
Post Reply