INTERACT FORUM

Please login or register.

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

Author Topic: Why does JRiver move the "Style" field to the "Grouping" field when importing  (Read 7388 times)

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75

I have previously ripped a sample track using 4 formats: FLAC, ALAC, AIFF, and Wave.  All four file formats have the "Style" field populated correctly within the file.  I can confirm this by right clicking each of the files in Windows Explorer, selecting Edit ID Tag, and seeing that the Style field is correct for all four formats.  However, when I import the 4 files into JRiver, it seems to remap the information in the files' Style tag to the "Grouping" field in JRiver--but only for the ALAC, AIFF, and Wave files (FLAC maps correctly) .  Why does it do this, and can the behavior be modified to keep the Style field's data in the Style field in JRiver for all 4 files?  Thank you.

Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42372
  • Shoes gone again!

What ID3v2 frame are you storing style in?

Here's the list:
http://id3lib.sourceforge.net/id3/id3v2.4.0-frames.txt
Logged
Matt Ashland, JRiver Media Center

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75

I believe I am storing the Style data in TIT1 Content group description.

When I look in the file via Windows Explorer right click menu, “Vocal Pop; American Popular Song; Pop” appears in a field called “Style.”  All four file formats describe the field “Style.”  Indeed, this corresponds to Styles as used on the allmusic.com website which is the source of the data for the field (as referenced and automatically populated by dbpa on initial rip).

Style similarly appears as a Field Name in your wiki on File Properties (tags) page, applicable only to Audio, with Data/Edit type of String/Standard, and the following description: A musical style, typically used to further refine genre.  THIS is where I want JRiver to show the desired value (i.e., “Vocal Pop…”) for all four files.  It currently only shows it there for the FLAC file.

Another Field Name in such wiki is “Grouping”.  It is described as “For support of the iTunes Grouping field “ with a link to a forum thread, where Alex B describes Grouping as being linked with TIT1, and he and others provide good background for this field.  This is where JRiver is currently showing the desired value for 3 of the 4 files (ALAC, AIF, Wav).

I don’t know this area well enough to know if both what JRiver calls “Style” and what it calls “Grouping” are stored in the TIT1 “frame”.

Thank you for your help, and if I have not answered your question correctly, please let me know.  Thank you again.
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42372
  • Shoes gone again!

I checked the code, and the ID3v2 frame TIT1 maps to the Grouping library field.

Since the ID3v2 spec describes TIT1 as 'Content group description', this seems reasonable.
Logged
Matt Ashland, JRiver Media Center

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75

It does seem reasonable to map Style to Grouping (which is what is done for ALAC, AIFF and Wav).  However, it is also reasonable to map Style to Style (which is what is done for FLAC).

If you examine the code, isn't the ID3v2 frame TIT1 mapped to the Style library field for FLAC files?  Even though it may be mapped to Grouping for the other files?

Can the behavior be modified for ALAC, AIFF and Wav to keep the Style field's data in the Style field?

Thank you.
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42372
  • Shoes gone again!

If you examine the code, isn't the ID3v2 frame TIT1 mapped to the Style library field for FLAC files?  Even though it may be mapped to Grouping for the other files?

FLAC does not use ID3v2, it uses Vorbis comments.

I think you're looking for a grand unification of tagging that doesn't really exist.  There are different tag formats and field mappings will line up a little differently in each.  There's not always a right answer.  The mappings we use have been established from years of user feedback, trial and error, etc. so will only be changed if there's a clear technical basis and consensus from users.
Logged
Matt Ashland, JRiver Media Center

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75

Thanks.  I do understand that full unification across formats is not 100% attainable.  Just trying to get as close as possible.

So, do I understand correctly that there is simply no possible way for an individual user to overide the map from Style to Grouping, and force Style to map to Style for ALAC,AIFF and Wave?
Logged

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42372
  • Shoes gone again!

Sorry, but tag mappings aren't user configurable.

You could use Auto Import rules to move or set tags based on folders.  Or you could do batch processing once you import to reconfigure fields to your liking.
Logged
Matt Ashland, JRiver Media Center

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75

Matt, thank you for your help.  Before I try the Auto Import or Batch Processing work around you mentioned, I'd like to see if I can create a custom field during rip containing the data I want that will map to the MC's "Style" field.

I checked the code, and the ID3v2 frame TIT1 maps to the Grouping library field.

Can you look inside the code, and see which ID3v2 frame maps to the STYLE library field?  As we see, "Style" maps to "Grouping," so what maps to "Style"?  If X maps there, I should be able to get the data into a field called X during rip to facilitate the import into MC.

Thank you again.
Logged

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084

Can you look inside the code, and see which ID3v2 frame maps to the STYLE library field?  As we see, "Style" maps to "Grouping," so what maps to "Style"?  If X maps there, I should be able to get the data into a field called X during rip to facilitate the import into MC.

You might examine the raw tags in each file type using the Tag window.  The first line below the word "Tag" gives the file type, the duration of the track and the file size of the selected file.  Click on that line and you will see a list of the raw tags inside the file.  I verified that it works with Flac, WAV and mp4a (ALAC) files.  I didn't have an AIFF files.

Learn techniques like this and you can solve problems yourself.

Bill
Logged

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #10 on: September 19, 2013, 10:03:29 pm »

Thank you very much.  I took a quick look and indeed very illuminating.  I will use this and Matt's suggestion about Auto Import to do some testing.
Logged

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #11 on: September 21, 2013, 09:49:57 am »

Does anyone know if there exists something like this, which has a column for MC library fields, so I can see all the mapping and ask fewer dumb questions?  Thank you.

http://help.mp3tag.de/main_tags.html

A table that compares MC, iTunes, id3, dbpa, and mp3tag, would be ideal, if that exists.  I am planning on downloading mp3tag this weekend.

Even better would be that, in an Excel file, but I know I ask too much!  Any help is much appreciated.

Thank you.


Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #12 on: September 21, 2013, 12:03:19 pm »

A couple of times over the past couple of years I've asked for help putting together info so that I can update this table:

   http://wiki.jriver.com/index.php/File_Properties_%28tags%29#Predefined_Fields

Not a single person showed interest, so I think there's your answer.
Logged
The opinions I express represent my own folly.

Listener

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1084
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #13 on: September 21, 2013, 01:10:50 pm »

Does anyone know if there exists something like this, which has a column for MC library fields, so I can see all the mapping and ask fewer dumb questions?  Thank you.

http://help.mp3tag.de/main_tags.html

A table that compares MC, iTunes, id3, dbpa, and mp3tag, would be ideal, if that exists.  I am planning on downloading mp3tag this weekend.

Even better would be that, in an Excel file, but I know I ask too much!  Any help is much appreciated.

I note that you started a series of threads on the dBpoweramp forum and received little response and no willingness to change things to fit your idea of how things should work.

You have a particular need to unify tagging across file formats and ripping/editing/playback software that few other people share.  You need to make an effort yourself to understand how the s/w you use deals with tags.  I gave you a way to see the raw tags that MC gets.  MP3tag is another tool.  Make up the spreadsheet yourself.

Bill


Logged

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #14 on: September 21, 2013, 06:21:44 pm »


MrC, this table has been enormously helpful to me over the past year as I've researched and tested different things. I hereby offer my time and enthusiasm for the subject.

Listener, I appreciate the coaching, including how to best benefit from and share with this community, and how I come across. Truly. 

It must not show, but I have been doing quite a lot of testing and research myself.   MrC's explanation of custom tags in the referenced post is where I learned to create custom tags in dbpa and get them to display in MC. Before testing/creating a custom tag, I review MrC's listing wanting to align with existing conventions, and wishing everything in his table was aligned in a sortable, filterable way with data from many other great resources I come across (see below).

I figured that if these things exist...

http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:ID3_Tag_Mapping
http://wiki.musicbrainz.org/MusicBrainz_Picard/Tags/Mapping
http://wiki.hydrogenaudio.org/index.php?title=Metatag_Mapping
http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Metadata_Compatibility_1.1.6_changes

...that there existed somewhere something similar with a MC column.

I would not create my own mapping without at least asking first, especially since such mappings exist for iTunes, Mp3Tag, Foobar, and other software.

And posts like below are encouraging:

http://www.hydrogenaudio.org/forums/index.php?showtopic=102013
http://yabb.jriver.com/interact/index.php?topic=62389.0

I am also working through things myself so far testing DLNA, my Sonos, and iPod syncing through MC.

I am posting publicly the things I am most struggling with, and which are most halting my private progress.

When dbpa "Style" did not map to MC "Style" and I could not understand why, I knew I needed help, especially since my test custom "AMG Rating" in dbpa lined up so effortlessly with that same custom field in MC.  I have just started my tag examining using the raw tags trick Listener directed, but from a quick read it looks like while dbpa displays the field in its right click menu as "Style" that it nevertheless saves it really as "Grouping" behind the scenes in the file.

I have indeed started a spreadsheet in Excel, where I typed in the dbpa default fields that appear in the ripping screen.  To it, I have added JRiver fields from MrC's list that I am considering populating on each rip.  I am happy to continue adding to this Excel file and happy to share it.  If someone wanted to help me build in things the community cares about and needs, it will come out better.  I should probably start by trying to get MrC's entire list into Excel instead of just the handful I typed in.

Once it's in there, and I confirm I can get it to a "flat" table format, I will flag certain fields and customize useful pivot tables.  One will be a list grouped by those fields I've targeted to be populated in dbpa upon every rip, versus those that are set up in dbpa, but will be more "optional" on rip.  It will also show me the JRiver field name and whether it's a custom user field or not.  It will show me which of those fields will not survive an iTunes import and thus whether any info should be moved or duplicated to the Comments or Lyrics field so it can show in iTunes (most importantly, on an iPod screen).  I will be able to see and group the JRiver fields I am not using, and whether that's because I've already decided I will put such info into a different field, versus I have no idea what it might even be for.

Listener, you seem a bit put off that I first asked if some starting point for this existed already. I will chalk that up to my own failure to effectively communicate previously.  But, I have found several threads that lead me to believe there were some others who were playing in this space, so I thought I'd ask first. If I hadn't posted my earlier question, you would not have shown me the quite helpful way to see the raw tags. I did not know before.  Now I do.  Thank you.

That trick shows me a lot about the fields that dbpa puts in the file, and I see where MC puts them. It does not help me see the relationship between JRiver fields dbpa is NOT populating by default (and thus are not in the sample file) and how they look as embedded tags.


If nothing exists w/MC column added to these other lists, or even some "all fields populated with field names" test rip I could download, I suppose the best way for me to figure this out is to create custom fields in dbpa for each JRiver field that I can't find an existing dbpa field for, do a test rip where I populate every dbpa/JRiver field with the name of that field, import the resulting file into MC, examine the results, and record them in my Excel sheet for future reference.

As much work as that would be, I'd be willing to do it and give the results back to this community.  Just, please point me to anything that might already exist if there is anything so I am not re-inventing the wheel without realizing it.  For example, MrC, does your list already exist in Excel?  At a minimum, I'd be happy to take it, map the dbpa default rip window fields, do some test rips, logs and print screens and give it all back to you.  What other help putting together info are you interested in?

Thanks, everyone.
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #15 on: September 21, 2013, 07:37:43 pm »

That was a nice post.

Probably the most beneficial way to accomplish this would be to systematically create some tag-empty test files of the desired formats (mp3, flac, wav, aiff, etc.) and import them into an MC test library.  Create a view that includes each interesting column, populate the cells with the same value (in a column) for all files, and then use an external tag dumping tool to output the tag blocks of each file.

If you don't have too many test files, then you could create column pairs of MC field values compared against the value output from the Tag() function.  Eg, and expression column:

[Album] :: Tag(ALBUM)

This allows you to compare the cached field value stored in MC's internal database against the actual tag in the file.  When there are variations in the physical tag name, you could output several:

[Field X] :: Tag(FIELDX) :: Tag(_FIELD_X)
Logged
The opinions I express represent my own folly.

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #16 on: September 21, 2013, 10:45:13 pm »

Thank you.

This, amazingly, is not dissimilar to what I am looking at right now.

In my Testing Library, I have a Panes Copy, with Album Artist, track number, file type, genre, style, grouping and publisher up top...

...and file type, name, date, month, day, year, style, grouping, Label, publisher, encoding settings, rating, composer, UPC, catalogue number, artist, album, genre, Track number, duration, bit rate, filename at the bottom.

I rip 1 test track at a time in dbpa to a folder specified for Auto Import into MC...
...using dbpa multi-encoder, saving 4 file formats in the same Artist\Album folder for these tests.
...and then I select the latest test track in the pane to compare just those 4 files.

I will add MP3s to my test to make it 5 formats being compared.

This is what let me see deficiencies that certain file formats have with respect to dates, Style/Grouping, Label/Publisher, as well as complications around graphical/numerical ratings/half-stars.  Spoon confirmed for me (3 of 4 times) that the deviation on dbpa rip is truly unavoidable in three of the "standard" tags; thus, if it is important to me I will have to consider deriving my own custom field for it within dbpa upon rip (my own date field looks likely).

At Matt's suggestion, I played around with the auto-import.  The apply these tags...Add...Custom options are powerful and allowed one first test to work well to get the Grouping data into the Style field on import.  I suspect I will either live with that workaround (and vice versa FLAC's Style into Grouping) or, more likely, try and create in dbpa my own Style-type derived field that all 4 formats could populate and map to one MC custom field.  Once I get MC settled, I'll see what survives iTunes import (I.e. Grouping, not Style, and not a custom field, I presume).

I will look to see if any trouble comes from an unpadded track/disc # in ALAC files, but my naming scheme in dbpa seems to have gotten ALAC's file names to "01" so it looks like I'll take note, but pass on doing anything there.

I just added my first add expression column using your example

[Album] :: Tag(ALBUM)

So I see the benefit of that, and look forward to closer examination.  I am not sure what you mean by the third expression in the following yet, but I will play around.

When there are variations in the physical tag name, you could output several:

[Field X] :: Tag(FIELDX) :: Tag(_FIELD_X)


Anyway, this is all great, and I will take a closer look at all of this in the next couple of days and report back.  

Thanks so much for these ideas and encouraging words.
Logged

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #17 on: September 27, 2013, 04:43:58 pm »

My testing is coming along nicely.  Thanks to everyone for their help.  I was hoping you could please answer a couple questions and confirm my approach so I stay on the right track:

Steps taken:
1. Set dbpa to "Disable Tag Writing" and ripped to FLAC, ALAC, AIF, WAV and MP3
2. Set up MC custom view in a test library with the fields I am focused on, and imported the files
3. Confirmed in the Raw Tag window that there was little to no data
4. Input the name of the field as a test value for each file and field
5. Added 2 test Expression columns ([Style]::Tag(Style)::Tag(_Style), and similar for Grouping), which then displayed "Style::Style::", etc.
6. Have downloaded MP3Tag and Tag & Rename, and am experimenting with those

I have also copy/pasted MrC's table of MC fields into Excel and have taken a number if steps to "flatten" the data so it can be filtered and facilitates use of Pivot Tables. 

Here is a link to a gallery with both the Excel file and a screen shot:

http://www.pix01.com/gallery/97ACC078-B8DD-4BBC-B40E-183418EB3CE4/JRiver_Media_Center_Field_List/#

(I see the screenshot, but I do not believe the Excel file uploaded correctly.  How can I share it out?)

I have another Excel version where I am adding notes, starting to line up dbpa fields, etc.

I have the following observations and questions:

A. After I finish this testing, I will know precisely how MC stores each field's value within each of the file formats, and this will be very useful.  I note, though, that this method does not seem to allow me to see that MC will refuse to import dbpa's "Style" to its own Style field (for reasons I now do understand--this is not a complaint).  It just shows me that when I enter in MC a field value in Style it does put it there.  Do you agree to make the testing even more meaningful, I need to also rip a fully tagged file in dbpa to see how MC will import existing tags created by that particular software choice?

B. Back to my current testing, when I enter field values in the MC view, I see that the raw tag listing updates almost immediately, which surprised me.  I had thought that these raw tags are showing what is literally in the file itself; and that MC writes tags from its library to the file only when I select Update Tags from Library, which I had not yet done.  I must be incorrect on one of these points?  or am I missing something else?

C What is the purpose of the third expression in the format Tag(_Field_X)?  It currently adds nothing in the column's display after the last "::".  Did I misunderstand the syntax with "Tag(_Style)"?

I would greatly appreciate your help MrC, Listener, Matt or anyone else that can shed some additional light for me.

Thank you in advance.
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #18 on: September 27, 2013, 05:05:56 pm »

Sounds like you're making good progress.  Let's see if I can hit at least some of your points...

Re: copying/pasting the MC Properties page.  Sorry I didn't know you were going to do this.  I generate that page with a script, and it would have been easy to output to a single line the data you wanted.  :-(

To upload a spreadsheet, you can attach here via zip archive file.

I suppose if your goal is to see how tags are mapped from one tagging program when imported into MC, creating valid sample files for those programs is necessary.  It may also be useful to you to understand how IDv* tag variants are imported in MC.  But I don't mean to fill your plate full of food.

MC can be notified when there are external file changes.  This setting is on by default I believe.  This is how the raw tag values can be updated in "real" time.

That third Field() expression I gave was just to give you the idea that some tags, such as Disc Number may have various external names (according to the tagging program) and MC maps them all to Disc #.  So if you find that Field(Disc Number) is not returning results, maybe you also want to show Field(DISCC) or some such.  The idea was that you could add the variations to the expression so that you see which one is valid for which file format.  But do what works for you.
Logged
The opinions I express represent my own folly.

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #19 on: September 27, 2013, 05:42:30 pm »

I see now the Additional Options and choose file.

Here is the Excel file...

Can you open?
Is this useful to anyone besides me?

Thank you.
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #20 on: September 27, 2013, 05:54:14 pm »

I can open it.  It helped me find a dozen spelling errors, which I've corrected for the next update.

So you're planning on now adding additional columns, one for each tagging program or tag format?

btw. I generate that table on the Wiki from this flat table (segment):

Code: [Select]
Altitude                           ---   I    --- N --- N --- S --- N --- S --- N --- KEYWORDS                --- Camera's GPS altitude when photo was taken.  SEEALSO [[Photo_Tagging]]
Aperture                           ---   I    --- N --- N --- S --- N --- N --- N --- KEYWORDS                --- Camera's aperture setting used to create the photo. SEEALSO [[Photo_Tagging]]
Artist                             ---  AIVDT --- N --- Y --- L --- N --- S --- Y --- artist=;ar=             --- Track artist, or movie's director.  SEEALSO [[Album_Artist_and_Album_Artist_(Auto)]], [[YADB]]
Logged
The opinions I express represent my own folly.

Sapagrino

  • Junior Woodchuck
  • **
  • Posts: 75
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #21 on: September 27, 2013, 06:10:04 pm »

Thank you.

With respect to:

MC can be notified when there are external file changes.  This setting is on by default I believe.  This is how the raw tag values can be updated in "real" time.

Matt, could you help here?  I think MrC, above, is addressing the reverse of my question, which relates to the file being changed when there are changes in MC.  If I had told MC to write library tags to file, I'd understand the option MrC must be referring to would in turn cause the file change to update the raw tag values.  But, I had not written tags to file.  I just want to make sure that if I am doing testing, I am properly understanding what MC is doing.  My question was:

B. Back to my current testing, when I enter field values in the MC view, I see that the raw tag listing updates almost immediately, which surprised me.  I had thought that these raw tags are showing what is literally in the file itself; and that MC writes tags from its library to the file only when I select Update Tags from Library, which I had not yet done.  I must be incorrect on one of these points?  or am I missing something else?


Thanks again.
Logged

MrC

  • Citizen of the Universe
  • *****
  • Posts: 10462
  • Your life is short. Give me your money.
Re: Why does JRiver move the "Style" field to the "Grouping" field when importing
« Reply #22 on: September 27, 2013, 06:20:08 pm »

Sorry, I did answer for the reverse.

When Update Tags When File Info Changes is enabled, MC writes out the tag values when you make changes to MC fields.  This happens automatically.  Disable that if you don't want MC to do this.
Logged
The opinions I express represent my own folly.
Pages: [1]   Go Up