MediaMonkey forum

I very much hope that other enthusiasts of classical music will join me here in making suggestions to the developers of MM, on how to make MM more “classical friendly”.

How about a “Classical script/module” that would add all the needed features to MM to make it suitable for use with classical music? I for one would be perfectly willing to pay extra for such a module, to save myself all the aggravation of having to dance around software that was designed for an entirely different use.

I would like to see these additional fields in a classical music module:

<Composer>, <Work>, <Conductor>, <Orchestra>, <Soloist>, (CD)<Label>, and <Movement>.

The current fields “Artist” could possibly be re-named “Feature artist” or “Feature performer” or something to that effect, being the featured or “Drawing card” artist of the album, and “Album Artist” could be re-named “Performers” or “Soloists”. The field “Title” could (should?) also be re-named to “Movement”. Another useful field may be “WV #” or “Work Index Number”, (such as Köchel or BWV numbers) but it may be just as well to append them to the <Work> field (in brackets).

All of the above fields should work like the current “Genre” field, having a drop-down menu that is providing a list of previously entered names, and they should all be searchable (included in the Library).

Please let me know if I missed anything.

BTW - MM developers: Please either remove the current “Composer” field from the “Track property/Details” menu altogether, OR fix it so that it can be used the same way as Artist, etc., as it is causing problems in file formatting if one of the custom fields is also named “Composer”.

I second the above. Support for classical music would be a very big plus.

As anyone can tell from the responses here so far, don't hold your breath waiting for anything to happen in that direction. I have given up on Media Monkey.

FYI, we hope to fit some support for classical music in upcoming MM 2.5.

Jiri

I mean no disrespect, and certainly appreciate your position as a lover of Classical Music myself, but there is a larger point here to consider:

(1) The real issue isn't just MediaMonkey, its the ID3 specifications. That is where the true fault lies. With V2, they are making improvements and have begun offering a greater variety of tags to accomodate Classical Music lovers. Composer, Conductor, Band/Orchestra are an example of the improvements in ID3V2.

(2) Already on the MediaMonkey wishlists are several requests to accomodate an increased number of fields and I have seen comments from the developers that would suggest this is being seen with importance. Some have asked for specific fields while others have asked that all possible fields be included with the ability to personal tailor what fields you want on the Tag Editor. The problem with this is balance. If you add all the fields, even if they end up being blank, you will negatively affect performance: synchronization times will be slower, queries against the database for large music collection will be slower, and the size of the database overall could be significantly larger, even if you don't really use all the fields. That annoying white space is always an issue - I'm just not sure how much of an issue it would be with an Access database in this situation.

(3) Renaming fields would be inadvisable. I could see POSSIBLY doing this with a script, but you are entering VERY DANGEROUS territory. If there is no field for Movement in the ID3V2 specification, then you open yourself up for a host of potential confusion and errors. It might seem like a good idea, but I've done this and it can be extremely misleading, especially when using other utilities alongside MediaMonkey. If there is a field you want currently in the ID3V2 specification, then it is simply a matter of MM incorporating that field into their interface, not renaming current fields.

(4) MediaMonkey, from my own use of it, seems to have not really been designed for a lot of "custom information", not a fault of MM necessarily. Of the dozens of managers I have personally used and reviewed, MM is the more superior and less buggy overall. Part of the reason for that is that it isn't "bloated" with a host of custom information. That isn't a bad thing, it's just different. The other managers I've used which actually have "User" customized fields and "Other" customized fields (i.e., no associated MP3 tags), are filled with problems inherent to these customizations. It bloats the database, slows things down, opens the application up to numerous bugs, and only helps a portion of the user base as most people don't want to take the time to fill in information that won't be saved in their MP3 tags. I think it would be nice for MM to make allowance for some of this, but again, there has to be a balance which simply isn't ever going to please everyone.

I'm curious about your "Composer" field comment. MM is simply using the field as it is specified by ID3V2. I use it myself and have had no problems with it.

i second this petition

Clearly it is more difficult to categorize and/or retrieve classical music than other kinds of music. A classical music piece typically involves many more performers, movements and sub-genres than a standard pop piece. The data base structures that might work to organize 1000 pop pieces just are not adequate to handle even 10 classical music pieces.

I have a simple way to augment the MM organizational structure so that it can effectively handle classical music needs without overly burdening the development resources.

So far this forum has seen a lot of proposals for adding new columns like composer and conductor. While these columns sound interesting, we have to give attention to what level in the data base these columns are proposed. I think most people assume without much thought that these columns will be carried at the track level, because that is where most song properties are carried.

But if you think about it, many of the classical music fields need to be carried at the album (or musical piece) level. For example, the cast of an opera usually applies to the whole opera - not just a song in the opera.

So, we need to track many of the classical music fields at the album level. This could get complicated for developers if we tried to track, for example, every singer in an opera cast.

I have a simpler solution that I think would go a long way toward meeting the needs of classical music fans. All we have to do is manually record the album level fields, like opera cast or orchestra details, in the comments field of the right click, album level property box of MediaMonkey. Then if we could find some way to display the album-level comments while a piece was playing we could at least see who is singing the opera or whatever other album-level details we recorded. [Note, my proposal would not allow us to sort or select on opera cast in a true data base sense, but hey, beggars cannot be choosers].

So, I think if we added a few select columns at the track level as already proposed - and if we figured out how to display album-level comments properties we could meet a large portion of classical music needs. Just adding fields at the track level won't really meet classical music needs.

Not knowing the first thing about coding, I can only extrapolate from what I see being done here (with MM) and lately also with iPod. Because iPod can handle customized menus and MM can be synchronized with iPod, would THERE be a way to handle classical music more conveniently?

I certainly recognize (as so aptly pointed out by agapeincognito) that the main problem for classical music lovers is the way the music industry is handling their tags, and there is very little that we can do about it here. But then, we don’t really need to? I would be perfectly happy to manually add all the additional classical information into my MM database, as long as the additional fields are being handled by MM in the same way as the original tag info fields (which they are currently not - in version 2.4.).

And I have to ask again, isn’t there a way to develop a module for classical music that could be added to MM to handle those additional fields properly, which could be made available at an additional fee?

I would be perfectly happy to spend all kinds of time with the developers of the code to help them understand the needs of classical music lovers (of which I have about 50 years experience).

PS. current version is 2.5.2. I believe that 2.6 might have some improvements so keep your fingers crossed.

We indeed plan to add better classical music support in the next version. We will welcome any feedback during the alpha/beta testing periods so that the final result will be really useful for classical music collections.

Jiri

Not knowing how much the development team knows about classical music (except that there must be some lack of knowledge or they would have incorporated classical support from the beginning), I can only guess and try to give a brief outline on some of the essential needs of classical music lovers.

In a nut shell:
The existing “album” field should retain its current status and functionality for classical music as well.

I am currently appending the “Label” info (in brackets) at the end of the “album” field, but a separate “label” field would be nice for searching. Reason: classical music often markets the same recording under different labels in different years.

A “composer” field is more important than any of the following fields, it needs to function very much like pop music treats the “artist” field. (However, the artist field can not be used for composers as it is needed for the performers/soloists.)
It would also be very helpful if the composer field would pop up a previously entered composers name after entering the first letter, or come in the form of a drop-down menu that is providing a list of previously entered composers, to avoid having the same composer listed several times with different spellings (i.e. J.S.Bach and JS Bach and Johan Sebastian Bach).

A composer’s “works” (compositions) field is needed after the composer field, to record the name of the various works (i.e.: Piano Concerto No. 5 in E flat major op. 73 “Emperor", Kaiserwalzer op. 437, Partita No.2 for Violin in D minor BWV 1004 (transcribed by Pepe Romero), etc.).

I am currently appending the “cataloging” or “works/verzeichniss” numbers (i.e.: Bach Werk Verzeichniss = BWV 1042, Köchel = K.225, etc.) to the above “works” (custom) field, but a separate field would be nice for search ability.

A “conductor/orchestra” field is an absolute necessity, because the same composition often has been recorded by different orchestras and conductors, which is very important to serious collectors of classical music. And here again, if these two could have two separate fields, it would make searching for either so much better, as one orchestra can record the same composition under two or more different conductors (at different times).
And if you really want to please classical music lovers, again make these fields pop up a previously entered conductor or orchestra name after entering the first few letters, to avoid having the same name listed several times with different spellings.

All other fields could remain as they are, except in the help file, reference could be made that under classical use, opera casts, solo instruments, and the soloists, singers and performers, all could be entered in the “artist” field (which may need to be able to accommodate 200 or more characters), and possibly that the “movement” info (Ouverture (Largo, Allegro), II Allegro Moderato, 4. Finale. Presto e Scherzando, etc.)can/should be entered in the “title” field. I am suggesting it this way, because I found that the tag info often gets automatically captured in these fields under current conditions (current music industry track info appears to want to end up in these fields).

Jiri,
If you need more info or clarifications, please let me know, you have access to my email address in my profile. I am sorry that I cannot do any beta testing, I just don’t know enough about coding. I haven’t touched any betas in years.

No coding is required in beta's. You just use it as a normal release and look for bugs in the beta. You can also comment on new functionality and if it's implemented correctly.

olddog: What do you think of the ID3 frames-based solution I proposed in this thread? (look for the "Vivaldi" example in the 2nd post)

All the custom fields you are suggesting are already defined in the ID3v2 standard. It's "just" a matter of implementing them in MM.
I would strongly, strongly caution against defining new "custom" fields. This would be asking for trouble in the future!

Defining a single custom "type" field in a TXXX frame could be used to adapt MM for classical vs. pop music - for example by defining which fields are shown as column headers.
I think it's great for us classical lovers to discuss how exactly we'd like classical support to be implemented in MM but I can't emphasize enough one point:
It is of paramount importance that we do this in a way compatible with the ID3v2.4 standard!

Lowlander,
I used to agree with you on this in principle, but had to learn the hard way that I had nothing but problems with beta versions, couldn’t handle the bugs, so I resolved many years ago that I would not touch them again ever. Core of that problem is that I don’t understand coder’s lingo, which they insist on using, thus making intelligent communication nearly impossible.


MCSmarties,
WOW, that research is impressive, and I have to agree with you that it will be best for MM to conform to an existing standard and not implement more custom fields. In many of my past posts I have complained about the poor performance of the existing three custom fields, and even the existing “composer” field that is acting somehow different than the regular fields and should be improved (drop down menu) or done away with (so as not to interfer if one of the custom fields is named "composer").

What I proposed above should be considered an absolute minimum requirement for classical music, what you are proposing looks like a luxury system to me, that is something I had not dared to hope for. One small disagreement I have is, that I much prefer to have the movements separated in individual tracks. In fact, I have been wondering if it would be possible to introduce an artificial pause of 30 to 60 seconds between all tracks. But that’s a topic for another thread.

I think that simple logic dictates that the development team also needs to consider the popularity of the iPod and what impact it’s functionality will have on the future of music managers. Whatever tag system it uses will likely become the future standard. I don’t own one yet (waiting for the price to drop), but I am intrigued by the possibility of taking my music and all its data with me to a record store, so that I no longer end up buying new records that I already owned, but forgot. (If any reader finds that strange, then just wait till you get to be 70. Its not something I want, but nature is doing to me against my will.)

You can use whatever lingo you want here on the forum. Just explain things well in whatever lingo is confortable.

Of course bugs (and normally there are some) can really mess up your library so it's only for those willing to take that risk.