As i was tagging my library I noticed that in many, instances once I selected the album I wanted to tagg MB moved automatically the album it identified and suggested the tagged album in the right column.
THis is fine for most files. However in for 27 Greatest Hits albums that i had, MB performed this function It identified them and put them in the right column as an album tagged for the bee gees. I deleted the album from my server and re ripped it again and passed it again through MB and MB tagged it correctly.
IMHO It would have been better MB did not move automatically moved the files to the proposed album in the right column, But would leave them in the center column and we would then have the opportunity to perform a lookup if all is well accept and save the new tag if not we would then scan the files in the center column and MB would then recognised the correct album and artist. and propose it in the right column In this way we can truly correct the corrupted taggs we currently have in our library.
Yeah, do agree here. It can be more comical if you are like me and download all artwork available. This can have a mad effect if the release I have is scattered between other releases. All of the bad matches chugging away and downloading artwork that I’ll then discard as I drag back to the left.
It is possible to drag all the files back to the left again, but sometimes I loose tracks this way. Not ideal.
It happens more when a release isn’t even in the MB database.
Have you looked into the OPTIONS at METADATA and PREFERRED RELEASES?
There is a section that lets you tweak the matches. In your example where you are looking for a Greatest Hits album, if you put that COMPILATION slider to the RIGHT and light up more of it in blue then the matches will bias towards compilations.
I am not quite sure what you mean. Picard would not automatically move anything to the right unless the files had been previously tagged with MusicBrainz identifiers , probably mistakenly in your case.
If the files included the MusicBrainz IDs (MBIDs) for the release and the recordings Picard would indeed by default move them directly to the right. This is actually an important use case for people who want to update tags in already tagged files. You can opt out of this behavior by enabling “Ignore MBIDs when loading new files” in Options > General.
If the files do not contain the MBIDs Picard does not automatically move them to the right. It will only do so if you explicitly use the lookup or scan functions or if you manually drag the files to releases or recordings on the right.
What is the use case for this? You basically would just end up with a plain list of files on the left and a bunch of loaded metadata on the right without any connection between the two.
How do you get AcoustIDs into the tracks without them jumping to the right?
If I have a Release that is not in the database I find myself dancing back and forth with false matches. Something like the following happens…
Starting with some freshly ripped by EAC tracks on the left
I have to press Scan to get the AcoustIDs into the tracks
Tracks are moved to the right, but matching random releases.
Have to drag the tracks back to the left
Do a CD lookup… nope.
Do a Lookup on the tag names… still no correct matches… drag files back to the left
Do a “Lookup in Browser” and poke around a bit
Add Cluster by Release…
Press TAGGER button from Web Browser
Do a “Lookup CD” and attach the discID
Finally able to do a “Lookup CD”
Now drag the files across to the right (or press “Lookup”)
Submit the AcoustIDs
That is an example of a “dance of the columns” I often hit. This is worse for me as I like to have all the artwork downloaded… which can be a comedy headache on the initial false match if I am in an artist with 200MB of PNG files attached! (See Tori Amos for a good example)
@IvanDobsky explained it as well as I could. Often I will scan a release that failed on lookup, and the result will be several different releases, one of which MIGHT be the one I want. Classical is especially bad for this since often the tags as ripped bear little resemblance to CSG, but it happens plenty with obscure compilations and VA albums, too. It happens less often with lookup, but sometimes if there’s a bunch of poorly tagged tracks that don’t cluster well, it’s an issue there too.
Here is an idea. Maybe have a menu option within the AcoustID button that just causes a lookup and updating of the tags but doesn’t shuffle to the right? “Calculate AcoustID” instead of the full “Calculate AcoustID and Lookup AcoustID to perform a match” as it is now.
This sums up what I rattled on about on a couple other threads.
Having a cluster get set to 27 different releases, some go to an Artist Compilation, some go to one of that Artist’s releases, hopefully one of them loads the “correct” one so you can then drag the rest of them back to it.
…and then there’s all that artwork downloading, for stuff that’s just going to get dumped.
(and think about when this happens against one of those giangantic box set releases that has every cut/mix of XXX track, is the absolute ultra uber every single track no matter what discography of that artist… and it has a 27 page booklet.
So, load results, and do nothing more would be really nice. When they get sent to the Right, since there are MBIDs now, they -should- all just load to the desired/proper release, or I’m going to look up the release myself and put them in it. Whatever.
Think of all the unnecessary queuing to the Cover Art Archive servesr that would be saved.
Yeah - I see the steam coming out of the back of my computer when I hit a bad one of these. Worst case is when I have a CD that doesn’t yet happen to be in the database, but is full of single releases for a popular bad. Singles that have been re-released in compilations and greatest hits. Wow can than get messy!!
It is also exaggerated as there is no “stop downloading the art” button. (Also see my other thread about some Releases having 1.8GB of art attached! )
(See Tori Amos for a good example)
)