Yeah, it's a shame that there doesn't seem to be any standard in audiobook tagging so it largely depends on personal preference.

Personally I use the following:

[list][*]Narrator/reader - Artist
[*]Author - Album artist / composer
[*]Book name - Album
[*]Book series - Grouping
[*]Series order - Disc#[/list]

Having the series order in the Disc# tag means I can sort books in order from first to last which is useful for auto playlists. I also like having the performer in the Artist tag because that's consistent with other media types.

Hi, I am using Media Monkey to manage my audiobooks (as well as for music), and it's the best solution I've found, but there are a few things that could make it even better.

There is a metadata tag TIT3 that is used by some other apps for SubTitle (Mp3Tag, WMA, WMP) and can also be viewed/edited in Windows File Properties but which I can't find in Media Monkey. It would be great if support for that could be added.

I use custom fields for "Read By" / Narrator and Series - It seems weird that there aren't standard tags for those defined by the audiobook powers that be! If standards ever do emrge, I hope you will support them.

Thanks for considering add SubTitle,

Liz

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.

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.

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>)) [b]$If(<ALBUM_SUBTITLE>, <Album> (<ALBUM_SUBTITLE>))\<Album>)[/b]\$If(<Disk#>, CD <Disk#>)\<Song#:2> - $If(<Interpret>=<Album Interpret>,,<Interpret> - )<Titel>

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

[quote="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.[/quote]

I agree with you. I'd love to be able to [i]take it with me[/i]

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

Cheers, David

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.

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.

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.

[b]Anamon[/b]: 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.

I'd like to add a wish of my own here: do [b]NOT[/b] 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.

[quote="stankovic"]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)[/quote]

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 ([b]Subtitle[/b] = Subtitle or [b]Subtitle[/b] = 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.
:)

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.

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".