INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: MP3 Tagging  (Read 11768 times)

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
MP3 Tagging
« on: February 24, 2009, 04:51:00 pm »

Quote
13.0.127 (02/23/2009)

10. NEW: If the field "iTunes Compilation" exists, it will be read and written to ID3v2 MP3 tags using the TCMP frame.

It's nice to have support for a new field, but you forgot my ID3v2 bug reports.

A TCMP frame in the file was just ignored and didn't cause any problems, unlike the bugs I have reported.

... the TXXX (DATE) ID3v2 MP3 frame should be renamed as I have said before. It causes problems with other programs which may combine the TYER and TXXX (DATE) values. It would be logical to use TXXX (JR_DATE) instead.

I attached a sample file. Its various erroneous "date" values are the result of reading and writing the tags a few times outside MC after the file was initially tagged with MC13. The year was initially 1984.

Also, as I have said before, the TXXX (Band) tag causes similar problems. An external program may combine a TPE2 (aka "Band") tag and a TXXX (Band) tag and interpret them as a tag with multiple values. I tried Mp3tag and foobar. Both programs write the values back to multiple TPE2 values. They cannot write a TXXX (Band) tag because the "Band" tag name is linked with the TPE2 tag frame. The obvious solution would be to use TXXX (JR_Band) instead of TXXX (Band).

A new sample is attached.

The sample files are in the original thread.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42442
  • Shoes gone again!
AlexB: MP3 Tagging
« Reply #1 on: February 24, 2009, 04:54:06 pm »

It's nice to have support for a new field, but you forgot my ID3v2 bug reports.

A TCMP frame in the file was just ignored and didn't cause any problems, unlike the bugs I have reported.

The sample files are in the original thread.

Thanks for the reminder Alex.

The TPE2 issue is tricky.  It seems that Windows standardized on TPE2 for album artist.  That leaves TXXX(Band) for the band.  I don't see how JR_Band is much better -- JRiver specific tagging was a major complaint we addressed when rewriting the MP3 tagger.
Logged
Matt Ashland, JRiver Media Center

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
AlexB: MP3 Tagging
« Reply #2 on: February 24, 2009, 05:11:52 pm »

TPE2 is fine as it is now.

TXXX (Band) is not fine and fixing it is not tricky. Just trust me and change it to TXXX (JR_Band) or similar.

The FLAC tag JR_Date is already in use and I think JR_ would be a good prefix whenever it is needed.

You may remember, that originally, when the ID3v2 tags were redefined, I suggested that the library field Band could use TXXX (Orchestra) instead of TPE2, but since MC has now a separate library field for orchestra that is not an option.

TXXX (Band) and TXXX (JR_Band) are both equally nonstandard or standard, but only TXXX (Band) causes problems with other programs. The other programs that can use TXXX frames get confused because they read TPE2 and TXXX (Band) as two instances of the same field. Please check the sample file I uploaded: http://yabb.jriver.com/interact/index.php?topic=49850.msg341136#msg341136

These programs do not have problems with accessing and editing a frame like TXXX (JR_Band) or any other custom TXXX frame as long as the name is not mapped to a standard ID3v2 frame (like Date or Band).
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
AlexB: MP3 Tagging
« Reply #3 on: February 25, 2009, 06:32:22 am »

I forgot to include this in the ID3v2 bug reminder:

Another bug:

MC writes a TYER frame to ID3v2.4 tags. It should be used only with ID3v2.3. TDRC has replaced it in ID3v2.4.

I just checked the frame header. It has not been fixed yet.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
AlexB: MP3 Tagging
« Reply #4 on: February 25, 2009, 09:03:34 am »

Regarding to the TPE2/Band issue here is the defination of TPE2 (which is now in a different use):

TPE2 = Band/orchestra/accompaniment

If you really dislike TXXX (JR_Band) you could consider using TXXX (Band/accompaniment).

It would kind of conform to the original defination, except that orchestra is not included because it is a separate library field.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42442
  • Shoes gone again!
AlexB: MP3 Tagging
« Reply #5 on: February 25, 2009, 11:54:22 am »

MC writes a TYER frame to ID3v2.4 tags. It should be used only with ID3v2.3. TDRC has replaced it in ID3v2.4.

I wonder if the easiest solution would be to just write TDRC in v2.3 and v2.4 tags (and also TYER in v2.3 tags).  While not perfectly standards compliant, it's more standard that JR_Date.

Thoughts?
Logged
Matt Ashland, JRiver Media Center

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: AlexB: MP3 Tagging
« Reply #6 on: February 25, 2009, 12:32:34 pm »

I have not tested this, but if a TYER and a TDRC field exist in the same file some programs might show values like 2004/2004 similarly like TYER and TXXX (Date) can cause problems with programs that combine the values.

Would it be difficult to just change the used frame according to the used ID3v2 version?

I am not suggesting that you should fully implement the complex TDRC system that can store precise time stamps. Just write the year value to TDRC instead of TYER if the version is 2.4. All other programs that support v.2.4 seem to do only this and nothing more.

The TXXX (Date) vs TXXX (JR_Date) problem is a separate issue. The frame is used for storing the internal precise date value (Excel style) and that style is not anyhow mentioned in the ID3v2 standards. Any valid TXXX field with a description conforms the standard and when the field usage is proprietary it is absolutely correct to use a unique description to avoid confusion with other programs.

The TXXX system still provides a way to access the proprietary and user fields inside and outside MC in a way that was not possible when MC used COMM frames with the additional "Media Jukebox" header string that was not part of the library field's name.

EDIT

I wrote this in the other thread:

Actually, quite similarly like I suggested the ID3v2.3 standard provides designed fields for the Year, Day-Month and Time values:

ID3v2.3

TYER
The 'Year' frame is a numeric string with a year of the recording. This field is always four characters long (until the year 10000).

TDAT
The 'Date' frame is a numeric string in the DDMM format containing the date for the recording. This field is always four characters long.

TIME
The 'Time' frame is a numeric string in the HHMM format containing the time for the recording. This field is always four characters long


In the newer ID3v2.4 standard TDRC replaces the three old frames:

TDRC
The 'Recording time' frame contains a timestamp describing when the audio was recorded. The timestamp fields are based on a subset of ISO 8601. When being as precise as possible the format of a time string is
yyyy-MM-ddTHH:mm:ss  (year, "-", month, "-", day, "T", hour (out of 24), ":", minutes, ":", seconds),
but the precision may be reduced by removing as many time indicators as wanted. Hence valid timestamps are yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and yyyy-MM-ddTHH:mm:ss. All time stamps are UTC. For durations, use the slash character as described in 8601, and for multiple non-contiguous dates, use multiple strings, if allowed by the frame definition.


Unfortunately most programs and devices don't follow these standards and can handle only plain year values. It is better to continue writing only the year value to TYER or TDRC and use a proprietary TXXX frame for the precise value (... but not TXXX (DATE) as I explained).
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: AlexB: MP3 Tagging
« Reply #7 on: February 25, 2009, 01:02:45 pm »

In addition, there is still the issue with externally edited year values when the file contains a "JR Date" tag that has a preference when the tags are read. This problem exists with all tag formats, not just with ID3v2. (This is the actual topic in my other thread.)

A quote:

How about instead leaving it the way it is now but on reading, if the year in the date tag is different from the JR_DATE year, return the date from the DATE tag instead? When/if the tags are rewritten in MC we can go back to getting the high precision date.

In your "offset" method it seems that if one changed the DATE in an external program to another year then the offset information is really invalid anyway.

Actually, I think the easiest solution would be to not write a precise date value to a separate tag when the Date field contains only a simple year value. That would fix the potential problem for most users. Also, if a more precise date value in the library is changed to a simple year value the JR_DATE tag should be removed from the file.  ...
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: AlexB: MP3 Tagging
« Reply #8 on: February 25, 2009, 01:21:58 pm »

As a test, I selected a file with ID3v2.4 tags and I changed the library date value from 1994 to 1991:

MC's tag dump:
Quote
MPEG-1 Layer 3
213 Kbit VBR
44.1 Khz Joint stereo

Copyrighted: No
Original: Yes
Protected by CRC: No
Encoder: LAME
Gapless: Yes (576 start, 2040 end)

ID3v1 Tag: (128 bytes)
   Name: Main Titles
   Artist: Vangelis
   Album: Blade Runner
   Year: 1991
   Comment:
   Track #: 1
   Genre: Soundtrack (24)

ID3v2.4 Tag: (2219 bytes)
  TIT2 (Name): Main Titles
  TPE1 (Artist): Vangelis
  TALB (Album): Blade Runner
  TRCK (Track #): 1
  TYER (Year): 1991
  TCON (Genre): Soundtrack
  TSSE (Encoding Settings): LAME 3.98.2 -V1 --noreplaygain
  TBPM (BPM): 97
  TDRC: 1994
  TXXX (Date): 33239
  TXXX (Intensity): 1
  TXXX (replaygain_album_g..): +2.11 dB
  TXXX (replaygain_album_p..): 0.976617
  TXXX (replaygain_track_g..): 2.530000 dB
  TXXX (replaygain_track_p..): 0.9008899927139282
  TXXX (Tool Name): Media Center
  TXXX (Tool Version): 13.0.128

The contents of the file properties window in foobar 2000 after the change:
Quote
Artist Name : Vangelis
Track Title : Main Titles
Album Title : Blade Runner
Date : 1991; 1994; 33239
Genre : Soundtrack
Composer :
Performer :
Album Artist :
Track Number : 1
Total Tracks :
Disc Number :
Total Discs :
Comment :
<BPM> : 97
<ENCODING SETTINGS> : LAME 3.98.2 -V1 --noreplaygain
<INTENSITY> : 1
<TOOL NAME> : Media Center
<TOOL VERSION> : 13.0.128
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42442
  • Shoes gone again!
Re: AlexB: MP3 Tagging
« Reply #9 on: February 25, 2009, 02:31:25 pm »

Coming next build:

Changed: The "Band" field is saved as TXXX(JR/Band) in an MP3 ID3v2 tag instead of TXXX(Band) to avoid conflicts with some software that considers TXXX(Band) the album artist.
Changed: The "Date" field is saved as TXXX(JR/Date) in an MP3 ID3v2 tag instead of TXXX(Date) to avoid conflicts with some software that considers TXXX(Date) the year.
Changed: ID3v2 tagging used TDRC for date storage and removes other date fields when writing ID3v2.4 tags.
Logged
Matt Ashland, JRiver Media Center

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: AlexB: MP3 Tagging
« Reply #10 on: February 25, 2009, 04:21:11 pm »

Thanks. I tested the changes quickly.

Interesting that you fully implemented the TDRC features. Despite my skepticisms it seems to work fine also with foobar 2000 / Mp3tag / Winamp even though those programs don't parse a precise date value anyhow. It is clever to write just the year when a more precise value is not tagged in the library field.

I think I found a small bug in ID3v2.3 tagging. When a precise date & time value is entered only the JR/Date frame is updated. The TYER frame and also the ID3v1 year remain unchanged even when they should have changed. Also, MC cannot read an externally changed TYER value if a JR/Date frame exists (but that is not a new bug). I wonder if you could just not write (or remove if exists) the TXXX (JR/Date) frame when it is does not add greater precision to the year value in the TYER frame. That would probably resolve 99.9% of the potential problems.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42442
  • Shoes gone again!
Re: AlexB: MP3 Tagging
« Reply #11 on: February 25, 2009, 04:39:54 pm »

I think I found a small bug in ID3v2.3 tagging. When a precise date & time value is entered only the JR/Date frame is updated. The TYER frame and also the ID3v1 year remain unchanged even when they should have changed.

I can't reproduce that.

Quote
I wonder if you could just not write (or remove if exists) the TXXX (JR/Date) frame when it is does not add greater precision to the year value in the TYER frame.

That's a very smart idea.
Logged
Matt Ashland, JRiver Media Center

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: AlexB: MP3 Tagging
« Reply #12 on: February 25, 2009, 04:49:34 pm »

I can't reproduce that.

Nor do I.  ?

Perhaps I did something hastily (like didn't update the tag dump before checking the values). Sorry about the false alarm.

Quote
That's a very smart idea.

I know...   ;)

It isn't a new idea, I presented it in the older thread, but maybe my explanation wasn't clear:
Quote
Actually, I think the easiest solution would be to not write a precise date value to a separate tag when the Date field contains only a simple year value. That would fix the potential problem for most users. Also, if a more precise date value in the library is changed to a simple year value the JR_DATE tag should be removed from the file.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

vagskal

  • Citizen of the Universe
  • *****
  • Posts: 1227
Re: MP3 Tagging
« Reply #13 on: July 21, 2009, 08:53:44 am »

Sorry for replying to such an old thread, but I was referred to it.

Alex B, or some other knowledgeable person, I wonder if you could be so kind as to explain how I can import the ID3v2.3 tag TORY in mp3 files. Below is an example of the tag information in the file (as displayed by MC). I am using MC13.

I understand that a new field/tag in MC must have a name that corresponds exactly to the tag name in the file. I have managed to get it to work for "Organization", "COMPILATION" and "iTunes Compilation". I have given the new field in MC the name "TORY" of data type String, but the information in that tag does not show up in MC. What am I doing wrong?

(I have read i.a. this thread on how to make new fields: http://yabb.jriver.com/interact/index.php?topic=43221.0 and updated the library from the tags.)

Could it be that an ID3v.2.3 tag without a "real" name besides it in parenthesis (like "TCMP (iTunes Compilation)", which I succeeded to import) when displayed by MC, cannot be imported? If so, is that likely to change in MC14.

An unrelated issue is that I also cannot import the MOOD tag and it is not imported automatically to the existing Mood field in MC. This is not so important to me, but I wonder if this could be due to the fact that I cannot create a new field with the name Mood since there is already one? Where is the existing Mood field supposed to get its tag data from?

Quote
MPEG-1 Layer 3
256 Kbit CBR
44.1 Khz Stereo

Copyrighted: No
Original: Yes
Protected by CRC: No
Encoder: <unknown>
Gapless: No

ID3v1 Tag: none

ID3v2.3 Tag: (48289 bytes)
  TALB (Album): Tea & Symphony: The English Baroque Sound 1967-1974
  TPE1 (Artist): Vigrass
  COMM (Comment): Min musik
  TCON (Genre): Pop/Rock
  TCMP (iTunes Compilation): 1
  TORY: 1970
  TPUB (Publisher): Castle
  TIT2 (Name): Stop
  TRCK (Track #): 4
  TYER (Year): 2007
  TXXX (replaygain_album_p..): 1.056819
  TXXX (replaygain_track_g..): -5.83 dB
  TXXX (replaygain_track_p..): 1.015947
  TXXX (replaygain_album_g..): -7.45 dB
  TXXX (Album rating): 4.5
  TXXX (Style): Baroque Pop
  TXXX (Mood): Precious, Delicate, Dramatic, Innocent, Autumnal, Sophisticated, Literate, Refined/Mannered, Elegant
  TXXX (Theme): Sunday Afternoon, Rainy Day
  TXXX (Review): <too large to display>
  APIC (Image File) (Cover): <too large to display>
Logged

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: MP3 Tagging
« Reply #14 on: July 21, 2009, 10:06:04 am »

Many of the less common predefined ID3 frames can be considered as suggestions for the program developers. Each developer can pick what seems appropriate. I am not aware of any single program that supports each and every ID3 v.2.x tag frame that is defined in the informal ID3 v2.3 and ID3 v2.4 standards.

TORY is not one of the currently supported tag frames and there is no way to read or write it unless the JRiver developers decide to add support for it.

The Mood library field is linked with the MusicMatch Mood ID3v2 comment frame and it works as intended. This Mood tag was introduced in the now discontinued original MusicMatch Jukebox program many years ago. The JRiver developers added support for it and several other, mostly proprietary, MusicMatch tags because many former MMJB users requested support for their existing tags.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

vagskal

  • Citizen of the Universe
  • *****
  • Posts: 1227
Re: MP3 Tagging
« Reply #15 on: July 21, 2009, 12:34:36 pm »

Many of the less common predefined ID3 frames can be considered as suggestions for the program developers. Each developer can pick what seems appropriate. I am not aware of any single program that supports each and every ID3 v.2.x tag frame that is defined in the informal ID3 v2.3 and ID3 v2.4 standards.

TORY is not one of the currently supported tag frames and there is no way to read or write it unless the JRiver developers decide to add support for it.

The Mood library field is linked with the MusicMatch Mood ID3v2 comment frame and it works as intended. This Mood tag was introduced in the now discontinued original MusicMatch Jukebox program many years ago. The JRiver developers added support for it and several other, mostly proprietary, MusicMatch tags because many former MMJB users requested support for their existing tags.

Thank you, Alex B, so much for the prompt and clear - but disappointing - answer!

May I try your patience with another question? I am a new user trying to evaluate if MC is the music management software for me. I have discovered some great features so far, but the ability to read, and preferably also write, my most important tags is essential. I have a rather large library and retagging therefore means a lot work, which I am hesitant to invest especially if this means that tags that are important to me will deviate from the standard.

If I, in MP3Tag for instance, copy the contents of the TORY tag to a tag which I name, say, TRACKYEAR, then MC could import that tag (TXXX Trackyear) and write back to it (bot not the original TORY tag) if I create a library field in MC named "Trackyear"?

And now this question as a hopefully final test of your patience (and yes, I know that the question is also off topic): An absolute requirement for me is that my primary music management software can read all information stored in i.a. ARTIST and COMPOSER tags, which are essential. I have become aware of the fact that MC as yet does not support reading and writing of multiple ARTIST and COMPOSER tags (Vorbis comments) in one flac file. MC only reads one of the ARTIST and COMPOSER tags in one file. My question: Does MC _always_ read the first of those tags in the file as displayed by MP3Tag?

I like the functionality in MC, once the information has been retrieved, so much that I am considering to find a way to use MP3Tag to copy the information in the subsequent tags to the first one separated by a separator character (and yes, I do know that MC as yet does not support a list type Artist field), but this would only work if I can be sure that MC always reads the first tag.  A follow-up question would then be if you perhaps know of a script for MP3Tag that can do such copying. By searching the forums I have found a thread with an example of how to move, not copy, multiple tags to one tag.

I have tested and found that MC is "well behaved" when writing tags in that MC does not seem to touch ARTIST and COMPOSER tags (Vorbis comments) that MC has not read, i.e. a change in MC of the ARTIST tag read by MC is only reflected in that ARTIST tag and the other ARTIST tags in that file are not deleted or altered in any way. Can you confirm this?

And finally, just a comment as regards the Mood field: It seems rather odd that the tags written by a software discontinued for years is allowed to be imported into a field in MC which is blocking users of current tagging software (MP3Tag) to import tags retrieved from a very common tag source (AMG)... But as I said the Mood tag is not particularly important to me. BTW: I was a user of MusicMatch, but I have by now cleaned up my tags from that experience.
Logged

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: MP3 Tagging
« Reply #16 on: July 21, 2009, 03:02:15 pm »

Thank you, Alex B, so much for the prompt and clear - but disappointing - answer!

It is is possible that JRiver will add support for the TORY (id3v2.3) and TDOR (ID3v2.4) frames. In the past they have added support for new tags upon request (but I can't promise anything).

There would be a slight problem with the field format and name. Should it be stored as a plain year or as a precise date/time stamp?

This is the ID3v2.4 definition:
Quote
TDOR
   The 'Original release time' frame contains a timestamp describing
   when the original recording of the audio was released. Timestamp
   format is described in the ID3v2 structure document [ID3v2-strct].

ID3v2.3 allows only the year value:
Quote
TORY
The 'Original release year' frame is intended for the year when the original recording, if for example the music in the file should be a cover of a previously released song, was released. The field is formatted as in the "TYER" frame.

In addition, the displayed name inside MC would need to be carefully considered. For instance, foobar and Mp3tag handle the tag in FLAC and MP3 files differently. Mp3Tag displays ORIGYEAR and foobar displays ORIGINAL RELEASE DATE for both formats. Both programs write the standardized ID3v2.x frames, but if the file format is FLAC the tag name is exactly the displayed name as it is also in MC.

I would say that the correct way to handle the issue would be to name the library field as "Original Release Date" and set it to store the presice date value (it would always be possible to tag just the year if preferred). An ID3 v2.4 tag would store the precise time stamp (if tagged) and an ID3 v.2.3 tag would store only the year (i.e. use lesser precision). The FLAC tag's header would then be "Original Release Date" and the FLAC date/time stamp should be written as specified here: http://wiki.xiph.org/index.php/VorbisComment#Date_and_time.

Quote
May I try your patience with another question? I am a new user trying to evaluate if MC is the music management software for me. I have discovered some great features so far, but the ability to read, and preferably also write, my most important tags is essential. I have a rather large library and retagging therefore means a lot work, which I am hesitant to invest especially if this means that tags that are important to me will deviate from the standard.

If I, in MP3Tag for instance, copy the contents of the TORY tag to a tag which I name, say, TRACKYEAR, then MC could import that tag (TXXX Trackyear) and write back to it (bot not the original TORY tag) if I create a library field in MC named "Trackyear"?

It should work fine. MC uses TXXX frames for custom tags. Just create the library field and import the files (or use the "Update Library (from tags)" tool for updating the library).


With FLAC files it works without copying the tags outside MC if you just create an indentically named library field, for instance ORIGYEAR or Origyear (the case does not matter).


Quote
And now this question as a hopefully final test of your patience (and yes, I know that the question is also off topic): An absolute requirement for me is that my primary music management software can read all information stored in i.a. ARTIST and COMPOSER tags, which are essential. I have become aware of the fact that MC as yet does not support reading and writing of multiple ARTIST and COMPOSER tags (Vorbis comments) in one flac file. MC only reads one of the ARTIST and COMPOSER tags in one file. My question: Does MC _always_ read the first of those tags in the file as displayed by MP3Tag?

I like the functionality in MC, once the information has been retrieved, so much that I am considering to find a way to use MP3Tag to copy the information in the subsequent tags to the first one separated by a separator character (and yes, I do know that MC as yet does not support a list type Artist field), but this would only work if I can be sure that MC always reads the first tag.  A follow-up question would then be if you perhaps know of a script for MP3Tag that can do such copying. By searching the forums I have found a thread with an example of how to move, not copy, multiple tags to one tag.

I have tested and found that MC is "well behaved" when writing tags in that MC does not seem to touch ARTIST and COMPOSER tags (Vorbis comments) that MC has not read, i.e. a change in MC of the ARTIST tag read by MC is only reflected in that ARTIST tag and the other ARTIST tags in that file are not deleted or altered in any way. Can you confirm this?

And finally, just a comment as regards the Mood field: It seems rather odd that the tags written by a software discontinued for years is allowed to be imported into a field in MC which is blocking users of current tagging software (MP3Tag) to import tags retrieved from a very common tag source (AMG)... But as I said the Mood tag is not particularly important to me. BTW: I was a user of MusicMatch, but I have by now cleaned up my tags from that experience.

I am not sure if I can answer these questions without personally testing the behavior. Unfortunately I am rather busy with other things at the moment.

Generally speaking, as you may have noticed, tagging issues can be quite complex. There seem to always be various different "de facto" standards and formats. The developers try to fulfill user requests, maintain compatibility with the internal database, accross various file formats, with other programs and devices, with the online CD database and also maintain backwards compatibility.

However, the JRiver developers are responsive and there is a good chance that a well-grounded and clearly described feature request will be fulfilled sooner or later. I'd recommend starting a new thread for the tagging requests.
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

vagskal

  • Citizen of the Universe
  • *****
  • Posts: 1227
Re: MP3 Tagging
« Reply #17 on: July 22, 2009, 02:53:10 am »

Alan B,

Once again thank you so much for your quick response and your advice.

I will start a new thread with some feature requests and see what will come out of that.
Logged
Pages: [1]   Go Up