Multiple value field - GENRE imported tags

[dsmacdo]

Hi,

I have recently noticed a little annoying issue when importing files that were tagged by other software that contain multiple value fields (ie.: three genre values). Somehow, a non visible character seems to get inserted at the beginning of the genre field value when displayed in the media tree (node?).

I can correct this by renaming the genre value in the tree or simply use the backspace delete key at the first letter of the genre name.


Thanks for any guidance you may be able to provide.

(B.T.W. I am aware of the ";" separator to split multiple value fields within MediaMonkey if using it to tag.)

[Lowlander]

I haven't seen this with EAC, maybe the software you use is writing tags incorrectly. I suggest you offer a sample file for which this happens to support: http://www.mediamonkey.com/support/inde ... ets/Submit

[dsmacdo]

Thanks for your input lowlander

These files were tagged using MP3Tag and I had a look at the extended tags. There are in this instance, 3 separate fields and I cannot see the issue from within it. MP3Tag happens to use "\\" to create the fields and MonkeyMedia never seemed to have issues with this before until quite recently. Granted, both MP3tag and my MediaMonkey were recently updated so.....I'll try a couple of things and if all else fails, I'll open a ticket.

Thanks again

[dsmacdo]

An update: After having looked at this a little closer, I opened a ticket as I can reproduce the issue consistently and this only within MediaMonkey. Moreover, the issue seems to only be with MP3s with ID3V2 tags with multiple value genre fields. Flac files with multiple genre fields do not exhibit the same issue. I have not however tested any other multiple value fields as yet.

Importing MP3 files into the library indeed inserts a hidden (non printable/viewable) period in front of the 2nd and/or subsequent genre fields within the database. A view of the file and tag structure as viewed in a Hex editor is fine and the hidden period is not present.

The end result is that you end up with the genre being distinct and upon perusal of the genre node, a separate genre is created. For example, if you node already contains a genre "Jazz" and you import an MP3 wherein the second genre is "Jazz", you end up with a second genre listed at the top of the tree due to this inserted / non visible period.

[Lowlander]

I only work with Flac for new files which is why I don't see this.

[scott967]

I have had a problem along these lines. It had to do with a Unicode BOM (FFFE) getting inserted at the beginning of a genre field, but in this case it was easily evident in looking at the hex and using an SQLite viewer on the MM database. I'm not sure if MM or MP3Tag was the source of the BOM getting in there.

A secondary problem, is once you get this bogus Genre entry into the MM database, it gets presented in the drop-down list of genres for selection when updating the properties (database) so you can end up perpetuating the error. It would be nice if there was some way to purge the entries that are presented in the dropdowns.

What I ended up doing was going through the database (the search function was no good for finding these BOM prefixed entries) and finding and correcting all the entries with bad genres. Once I got rid of them all I deleted the genre from the database using my SQLite tool.

scott s.
.

[Lowlander]

http://www.mediamonkey.com/forum/viewto ... move+genre

[dsmacdo]

Sorry for taking so long to respond and thanks for your input Scott.

Thankfully, most of my music collection is in Flac which does not suffer from the same "glitch". I have manually corrected all the entries within MM but it remains quite a pain just the same.

IMHO, this is MM related issue. The tag itself (ID3v2) seems fine when viewed in hex. Your take seems interesting but alas, I fear that my skill set is not up to par to completely pin it down. I will test what happens within Foobar with my MP3s again in order to be sure that it doesn't happen within it. In my view, that should help to determine whether this is an issue within MM's handling of the tag. That said, I had to rebuild my system due to a hardware change & I fear that I'm about to have to clean it all up again as my structure has changed and I'll have to create a new database.

Lowlander: I'll have a peak at the script you pointed out. Thanks again.

Doug

[funkeyro]

I have not noticed anyone identify the multi-value field separator. Doesn't MM require semi-colons? Several Tag editors, including MP3Tag, use a comma to separate the values. I believe that MM interprets this as a string, and then adds it to your field database ie.: "Crime, Mystery, Action" instead of recognizing 3 separate Genres ie.: "Crime" and "Mystery" and "Action". As you might guess, I work with a lot of .mp4 files as well as .mp3 files, and this drives me a little nuts.

[Lowlander]

Tools > Options > Appearance, by default it is ; Do note that this doesn't reflect how multi-value fields are saved to the tags, this depends on the tagging standard.

[dsmacdo]

Hi Funkeyro,

MM by default uses the semi colon but can also be configured to use | under the options menu. As far as I know, Mp3Tag by default uses a double backslash.

Please note that I am in no way an expert at all this stuff and realize that tagging can be quite problematic as multiple media players or devices support one format but not necessarily others. My impression is that MM "officially" supports ID3V2 natively and thus, I was hoping that it would also handle much of the standard as defined. MM handles multiple genre fields & values with flac tags and I would have thought, that it would behave similarly with ID3V2.

MM does seem to understand that the file contains multiple genre values but for whatever reason, inserts a non-visible character on the second and subsequent field. I had a look at both the Flac's frame and equivalent frame contained within the MP3 file using a hex editor, and from my perspective, there is no difference whatsoever. Foobar does not seem to have an issue with the MP3 as tagged either.

At the request of support, I just tried to synch the tag from within MM and it seems to not re-tag correctly either. Despite having used the semi colon delimiter within MM's GUI, the resulting tag "merged" the separate fields into one. IMHO, there is indeed an issue with how MM handles ID3v2.3 tags. I had previously sent support the file (which was originally tagged with MP3Tag) and from what I got as a response, the file itself is fine. Please understand this is not to dis MM but rather, I am simply trying to resolve what I consider a "bug".

I am tagging in Unicode. Would anyone know if MM expects ISO- 8859-1 tags rather than UTF-16?

[Lowlander]

MM by default uses the semi colon but can also be configured to use | under the options menu. As far as I know, Mp3Tag by default uses a double backslash.

As said what is shown and used in MediaMonkey isn't what is read and written with the files themselves. The double backslash is the delimiter used in ID3v2 (used in MP3s) and MediaMonkey also adheres to that.

[dsmacdo]

Hi again Lowlander,

Thanks for confirming what I thought. Whilst the interface uses the semi colon, the effect on the file itself would/should be the same as the double backslash.

[TheEmpathicEar]

I thought the delimiter for Genre(s) in MM5 was either a comma or semi-colon?

[Peke]

Hi,
But some tag formats have specific standards how to write multi tags eg. ID3v2.3 MP3 TAGs had big issues with AC/DC when Multi artist standard was established. Problem is that still some hardware only partially support ID3v2.4 and that was the one of main reasons why only in MM5 ID3v2.4 was default format.