SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Compilation tag sometimes seems to change by itself

#1

I have my own custom use for the compilation tag, but Jaikoz seems to be behaving in unexplained ways, causing troubles.

Allow me to explain what I am trying to do, then explain what seems to be not working as expected.

My collection (15,000 tracks currently) is mainly played on Sonos, and my Sonos is configured to index using Album Artist rather than Artist.

I start with Musicbrainz data, but then modify quite a bit by hand. In particular, I want to use "Is Compilation" field for my own purposes, and thus I have set Prefs/Musicbrainz/Format/Is Compilation to "Never Alter".

> For albums which I want to handle as single artist, I set Is Compilation to No, and set Album Artist and Artist to be the same artist name.

> For albums which I want to handle as a compilation, I set Is Compilation to Yes, and set Album Artist to “Various Artists”, and Artist to be the individual track’s artist name.

In other words, I end up with Is Compilation = "yes" if and only if Album Artist = "Various Artists".

I then use Local Correct/Subfolder from Metadata for all files (Compilation or not) using:

ifnotempty(genre,folderseparator) + ifnotempty2(albumartist,artist,folderseparator) + ifnotempty(album,folderseparator) + (disctotal>1 ? discno + folderseparator : ‘’)

Finally, I then use Local Correct/Filename from Metadata for non-Compilation files using ifnotempty(pad(trackno,2),’ - ‘) + title , and for Compilation files using ifnotempty(pad(trackno,2),’ - ‘) + ifnotempty(artist,’ - ') + title .

Once all this is done, I then Save Changes and close Jaikoz.

Inspecting files and paths in Finder shows that my Local Correct actions all seem to have had the desired effect, and my Sonos system then indexes my files way I want it to based on this tagging scheme. So far so good.

The problem arises when I later reopen a folder previously set up this way (say, for example, to correct some errors).

On reopening, for some files the Is Compilation field comes up as "yes" for files where I had previously it set to "no". This shows up immediate I open a folder, though on only some files in an apparently random fashion, and without me doing any other actions aside from opening a folder of previously edited and saved files.

Can’t figure out what could be causing this, and can’t tell if the change occurs before I save or upon reopening later.

Ideas ?

#2

I understand your logic for the Is Compilation flag, this is how iTunes uses it as well and I am going to revisit it http://www.jthink.net:8081/browse/JAIKOZ-36

Matching from Discogs can also set the compilation flag, if you don’t want it to you need to modify Preferences:Remote Correct:Discogs:Is Compilation - so this may be the problem.

Whether or not this is the issue you are having Im not sure, what format are the problem tracks, if you have a mix of formats it would be interesting to know if the problem only occurs for a particular format (mp3, flac etc)

#3

good call, Paul. Turns out this is only happening on m4a files, of which I have only a very few. (Predominantly have Flac, plus a few mp3s.)

As to what’s causing this, Preferences:Remote Correct:Discogs:Is Compilation is set to “never alter”, so that’s not it.

A little experimentation shows that I can 1) edit an m4a compilation from yes to no in Jaikoz, 2) save the file, 3) close the file, then 4) re-open, then Lo, the compilation tag is back to yes, with no other actions on my part whatsoever. Also some checking shows that this happens to all my m4a files, including I am pretty sure to m4a tracks which should not be compilations by anyone’s definition.

Can’t tell if the m4a files’ compilation tag is being modified by my save action or my reopen action. I currently have no other tag inspector app which I could use to check between save and reopen. (Except iTunes, which I am wary of letting anywhere near my music library; iTunes doesn’t do flac, and anyway, I use it only for software update, etc.)

Any ideas how to stop this from happening? thanks

#4

So m4a that were never marked as a compilation are fine, the problem only occurs when Jaikoz marked it as a compilation and then you try to change it to be a non compilation.

What happens if you close Jaikoz down, reopen the files in Jaikoz and try again to make them non compilation, and then save, does that work ?

#5

Testing results:

step | action | result

1 | open Jaikoz | opens
2 | open m4a file | opens; “Is Compilation” tag shows checked in edit view
3 | uncheck tag | tag unchecked; marked as having unsaved edits in edit view
4 | save file | saved; unsaved edits mark gone; tag shows unchecked in edit view
5 | close file | file closed
6 | reopen file | opens; “Is Compilation” tag shows checked in edit view

I then did the same test, but between steps 5 and 6 I first inspected the file by adding to iTunes and using iTunes “Get Info”. iTunes shows the file as NOT part of a compilation. (As mentioned above, I normally don’t use iTunes at all for music, so it is not the culprit here.)

Oddly, then, it seems that Jaikoz Edit View is showing the compilation tag in my m4a files as set when in fact it is not.

The problem with this is that when I use Correct Filename from Metadata, Jaikoz then uses my compilation rename mask rather than my regular rename mask (my IP above refers), unless of course I remember each time to uncheck the compilation tag in Edit View first.

This is a problem I’d like to avoid. (Recall only the small portion of my stuff that is m4a has this problem.)

What are your thoughts, Paul?

Thanks

#6

Experimenting a bit further, I took an m4a file which iTunes shows as not compilation but which Jaikoz shows as compilation, and then in iTunes set the “is compilation” flag. Now, both iTunes and Jaikoz show the tag set to yes, so I assume the actual file itself is truly marked yes.

If I then edit this file back to no compilation using Jaikoz, iTunes will again show it back to its original state, without the flag set. But as above, reopening and viewing the file in Jaikoz, it once again disagrees with what iTunes shows.

Finally, FWIW, I have notice no other odd behavior of Jaikoz on these files, just the compilation tag always showing in edit view as set to yes.

#7

Raised http://jthink.net:8081/browse/JAIKOZ-704 to track this

#8

noted. thanks. will follow this.

as mentioned above, the workaround is to remember to inspect and manually set the compilation tag on m4a files to what I want it to be every time I open any such files, and before performing any action which is conditional on the state of this field, i.e. “Correct Filename from Metadata”. Needless to say, this is rather cumbersome. Hope this curious bug gets fixed in an upcoming release.

FWIW, Jaikoz is still the best multi-format tag manager out there, especially on the OSX platform for people who prefer to avoid iTunes for whatever reason, such as lack of FLAC support !

grateful for your fine work, Paul.

#9

I just registered the software and spent the evening getting it configured the way I want, when I noticed the exact same anomaly. I registered to post about it, but searched before posting and found this topic.

So if you need any info from another perspective, or want another tester, I’m willing to help.

bobm: I use the compilation flag for the same purpose you do, to flag actual compilations. I consider collections of music from the same artist to be more akin to anthologies than compilations. Nice to know there’s other sensible collectors out there. :slight_smile:

#10

Right Im looking at this bug now but mtwitty you might like to comment on http://jthink.net:8081/browse/JAIKOZ-36 its proving difficult to decide what to do with it.

#11

This was fixed in Jaikoz 5.7.0