compilation = 1 vs compilation = yes (can't fix with id tags)

[inphobia]

hello,
i have an issue with the standalone accuraterip where it's not detecting an album as compilation, it just lists it as 20 albums instead of 1. after browsing the forums did find a workaround, i'll add that add the end so this doesn't get confusing.

so, want to rip an album that was not yet known by perferctmeta, nor did it have an accuraterip entry.
( https://www.discogs.com/release/5824...In-The-Heavens )
i used the discogs import function (copy discogs url when perfectmeta is open), looked correct so i pressed rip.

rip worked fine, but when i ran the accuraterip app a bit later it reported the 20 tracks as 20 albums. and none of the other 30 compilations i ripped this week had the same issue. turns out i had forgotten to click the compilation checkbox when ripping. the "artist album" was also blank, but so were all my other compilations. so, added the compilation tag, reran accurterip, ... still nothing

long story short: the problem seems to be how the "compilation" label is defined. when you can only choose between yes/no. all my compilations that do work have it set to "1".
setting to "yes" seems to just be ignored, and i tried everything i could think of to try & force it to one.

i tried:
id tags: set compilation to yes on album level
id tags: set compilation to yes on each track
id tags: both of the previous but first removed compilation tag

enabled the windows explorer extension, tried adding it that way, in all previous permutations.

fixed in with metaflac, whichi is fine for a few files but perfectmeta's id tags a nicer experience
so:

metaflac --remove-tag compilation *.flac
metaflac --set-tag compilation=1 *.flac

this changes it from:
% metaflac --show-tag compilation 07_-_Rudolph\'s\ Hurry.flac
Compilation=Yes

to

% metaflac --show-tag compilation 07_-_Rudolph\'s\ Hurry.flac
compilation=1

and the accuraterip is happy (does not seem to matter if compilation is lower/uppercase or just start with a capital)


as for the workaround:
just set "album artist" to "various artists".

i'd guess somewhere in the metadata encoding/decoding flow there's an assumption that 0/1 == true/false == yes/no == checked/unchecked.

[Spoon]

If you want maximum compatibility then compilation=1 is the way to go, compilation=yes will break many players

[square]

I have nothing to add to Spoon's suggestion, but I'm curious:

1. Why do you insist on setting Compilation to "yes" when "1" works perfectly?
2. What makes you think you cannot use PerfectTunes to batch-edit the Compilation flag in your files?

Cheers
square

[inphobia]

actually i do have something to ad, that my actual problem is that i can't in any way to set this to "1" instead of "yes"

to answer your questions:

2: because i tried everthing i could think and nothing worked (verified with metaflac) but did not try options that to me make no sense like ripping the cd again or using dbpoweramp to convert from flac to flac to rewrite tags. i now realize i haven't tried either batch convert but a quick glance at the manual suggest it's it would have the same effect as a dbpoweramp.
i also did not try the commandline versions included with dbpoweramp, but i feel this can be justified, i'm way more proficient to get things done via cli that are not done on windows.

all options i tried via id tags or the explorer extension force me to make a yes/no choice, i can't type "1" ( this is no longer correct - follow up with reply to this post since i've been tripple checking, going through more iterations - it's alrdy to long will just get confusing)

depending which dbpoweramp or perfecttunes program you use i've also seen that some _show_ the the actual value, be it yes/no or not set/0/1 , while some will display a "1" as "yes"
i changed the ones i needed with standard flac's "metaflac", not very userfriendly but for simple bulk updates is works ok.


1: because i tested it
i also made a copy before i changed stuff so i had a valid baseline. it was perhaps a niche condition, so
if: album artist is blank
and: all tracks are in the same directory
and: there are no copies of the same file in other dirs (actually does not seem to matter - having a corrected version will show a complete album and the other as a bunch of files)
and: vorbis_comment block is otherwise correct:
album,tracktotal, disktotal,disknumber,genre,date,label (will list them all if you want)
accurateripdiskid: only last digit changes
title artist & accurip crc differ but are correct

(also cleaned caches between tests) - so the only thing changing is compilation being 1 or yes, the perfecttunes -> accuraterip will report the compilation=yes one as single tracks.

another way to get it to report a whole album is setting albumartist to "Various Artists" versus leaving it blank. only found that out later since my other compilations also left it blank but still worked.

i thought accuraterip would magicly detect that somehow, since i was at that time still wrestling with something else i couldn't explai

[schmidj]

I've used mp3tag to change the compilation tag to 1, very simple and you can change a whole bunch of tags at once. (in case you are not familiar, it is a free tag editor, works with just about all audio file types, not just mp3s, used by many people here on these forums along with dBpoweramp and Perfectunes.)

Accuraterip has nothing to do with tags like this, it only verifies that the checksums of the audio rips match, it doesn't read the tags (many of which are matters of personal taste, not necessarily correct or incorrect.

[inphobia]

(spent my time between previous and this post detailing & checking again that these are the most narrow set of parameters & complete set of starting conditions (dont want to fire of issue i know i dd not test with everything in my ability))

ok, so what does work

in id tags going to an album to the tracklist, select the compilation field with the mouse and typing "1"

regretfully also found several cases where it doesn't work that i couldn't determine what was going wrong.



testing prep:
closed id tags & cleared cache
newly ripped album using perfectmeta data that was correct on first try, compilation was ticked after detecting, ripped accurate, artwork added correctly, default rip profile
album showed as <various artists>, filesystem layout was created as various aritsts\name of the album
metadata via metaflac: tag album artist is not present, and then Compilation= (vorbls_comment comment[9]: Compilation=1)
made a copy after the first rip so i could retest if i was unsure
closed everything, cleared cache, accuraterip show 1 album
changed but likely not relevant: filesystem not alliowed charecter -> i change all result characters to underscore, and added a lot of more to get changed to _ (perhaps should just use force ansi)
closed id tags & cleared cache
i tested with close , clearing cache restarting - as well as just do everything in one session. this made no differnce
as such to keep it daable the following is can be reproduced by using

these are all in the id tags files & folders + tag edit mode when editing an album.
most of these have subtle differences, so to to keep it understandable these will all start with the following parameters:


==
what are you testing again?
-> all these tests are ways i was unable to get compilation=1 set on a track, either by adding as new tag, or updating existing.

-> --reset-- means set compilation=1 again on all tracks (can be via metaflac, found out how with id tags as well

[inphobia]

uuuuhhh, thankfully i started writing my reply in a text file since everything got cut off. not gonna reformat it over 5 posts, will add it as attachment.

[inphobia]

I've used mp3tag to change the compilation tag to 1, very simple and you can change a whole bunch of tags at once. (in case you are not familiar, it is a free tag editor, works with just about all audio file types, not just mp3s, used by many people here on these forums along with dBpoweramp and Perfectunes.)

Accuraterip has nothing to do with tags like this, it only verifies that the checksums of the audio rips match, it doesn't read the tags (many of which are matters of personal taste, not necessarily correct or incorrect.

i seem to be doing a very bad job at explaining myself , or perhaps i just look at it a different way.

-> compilation tag
i see you replied in 20 minutes. as i ended my conclusion in the attached txt file "spent all my time from previous to this post writing this down" :-D

i can also better articulate my case: perfecttunes id tags often forced me to select yes/no, which in turn writes the string yes or no to the tag. i think i can get you in an inconsistant album state in less than 10 mouseclickls (excluding navigating to the album)

you raise a vallid point with mp3, it's to say: i've not considered this from anoher viewpoint as flac.

i have 17000 flac files that still have id3v1 tags. not allowed, now very rare sight but when i made them nobody cared about flac. the vendor blocks say the newest one was "reference libFLAC 1.2.1 20070917" and the olfest "reference libFLAC 1.1.1 20041001"

-> accuraterip
it has _almost_ ,nothing to do with tags. i might have found myself in a strange situation, but as you can see i've tried a load of option. already tested this, so can give this in a compact form.
all i need to do to change an album from accuraterip verified to to 3 albums with rip errors 13 albums accurately ripped is:
metaflac --remove-tag compilation *flac

you could stilll be technically correct if you specify "acuraterrip the verification method, not acuraterip the perfecttunes program" ;-D

[GBrown]

This is a really long thread discussion for something that's pretty straightforward. In the time it took you to write out just one of your posts, you could easily have downloaded and installed mp3tag, loaded all 17,000 of your FLAC files, filtered for all files where the Compilation field is currently "Yes", and reformatted these to be "1" instead.

[inphobia]

it is really long & went it in too many directions. it was also a fun one to dive into. the end result was a wall of text of what and why, in which i had been nose deep for several hours. what was meant as "i into this issue & i have a hunch this is the cause" got lost.

perhaps we can have a fresh start.

i'm not trying to make some statement - and since the thread title is a giveaway at this point this could come over as condescending. if that's the case: just lock or delete the thread.

---

i was wondering why perfecttunes accuraterip refuses to handle one compilation as a complete album but instead as a bunch of albums with 1 track







i tried perfecttunes id tags and to me they seem fine.

[simbun]

i was wondering why perfecttunes accuraterip refuses to handle one compilation as a complete album but instead as a bunch of albums with 1 track

It seems that PerfectTUNES requires the Compilation or AlbumArtist tag to be populated, which is standard practise but certainly isn't clear from the AccurateRip configuration:

PerfectTUNES > Settings > Library > Album Defined by:

• Folder and album tag
• Only by album tag

I don't have the registered version of PerfectTUNES so I can't test it, but if setting Compilation to Yes (the only option available in the UI) doesn't set the Compilation tag to 1 then it's a bug, and is probably what's causing PerfectTUNES to split the album as it doesn't accept Compilation=Yes.

Illustrate make some great products but PerfectTUNES AccurateRip isn't one of them; CUETools is a much better product for verification.

[Spoon]

Will note as an issue to look at.

[square]

Spoon The problem lies in how PerfectTunes translates the values for Compilation in the ID Tags window for display – but doesn't do so when writing tags. The PerfectTunes ID Tag window shows "Yes" when the value for Compilation is "1" or (literally) "Yes". This means that you cannot distinguish between these two cases just by looking at it. Conversely, the window shows "No" when the value for Compilation is "0" or anything else than "1" or "Yes".

On the other hand, when you try to modify the Compilation tag, PerfectTunes writes whatever you literally type into the text field: When you enter "1", PerfectTunes writes "1", but when you enter "Yes", PerfectTunes writes "Yes". You can try this yourself: Enter any string into the Compilation text field and have PerfectTunes write the tag. As soon as you reselect the files in the file list, the contents of the text field will change. But if you right-click the files and select "Edit Tags", the upcoming dialog confirms that what got written to the tag is actually the string you typed in.




I think the most robust solution would be to replace the text field with a checkbox and have PerfectTunes write 1 or 0, respectively – maybe like so (mockup):

[vilsen]

I think the most robust solution would be to replace the text field with a checkbox and have PerfectTunes write 1 or 0, respectively – maybe like so (mockup):

I like the checkbox solution. However, I think that PerfectTunes should write "1" if checked and nothing at all if unchecked. Reason being some reports that odd players only look at the presence of the compilation tag, ignoring the actual value. So they would take both "1" and "0" (or any other value) as a compilation.

Because of that, I've always followed the defacto standard to use the compilation tag only for compilations. I think it makes sense, because no player should need this tag for non-compilations.

A minor issue with a checkbox though: How should PerfectTunes handle an existing value of "yes"? To me that's an incorrect value which should not render a tick in the checkbox. But, if you would tick the unticked checkbox, any existing "yes" would be overwritten by "1". Some people might not like their tags being overwritten (even if they are non-standard).

Perhaps an alternative grey background colour in the checkbox could indicate "yes" while the normal white background is reserved to indicate "1"? Other ideas? Or is this essentially a non-issue?

[inphobia]

thank you for giving this a second chance after i just kept in to a single point.

also thanks to square for underscribing that a part of the issue comes from the type confusion. i'm reluctant to refer to it, but in a previous post in the thread i detailed several ways i shot myself in the foot trying to fix my initial error and (perhaps farfechted ways) i tried to fix it which just made it worse.