So… Doesn’t that mean there will be no match—and therefore no action taken—for files that do not comprise a complete album?
If so, then it isn’t working. I just tried it twice on a large folder full of loose files, and it moved many files that were not whole albums.
If unable to match all songs to an album and unable to fully match an album it can still try to match song only, this means it can correct song information like song title or artist but not album info like album title, albumartist or trackno. If you look at the MusicBrainz bar on the chart notice it says MusicBrainz Song Only
But anyway you have Rename files based on metadata set to Yes if matched to a release or song this means files are also renamed if matched song only, Also looking at the length of the Rename bar it seems that many of these songs have previously been matched to song or release so just because you didn’t match them on this run they are already matched, and hence the rename would have an effect.
Rename occurs at the end of the process and is based on the current metadata, it doesn’t matter when that metadata was added. This means SongKong works well with other MusicBrainz enabled taggers such as Jaikoz and MusicBrainz Picard.
BTW I think I recommended you enabled Only allow match if all songs in grouping match to one album but I don’t see much point in enabling Only allow match if all tracks in album were matched as well in your case.
I emptied the Database before I ran SK; I thought that would clear any previous matches. I guess not. How does one clear the match? I’m pretty sure I had “rematch” turned on, anyway. That is another switch that sounds like it’s going to apply only to this pass.
If a switch says “Only allow match if XX”, then it seems reasonable to expect that no matches should occur otherwise. Nowhere is it made clear that this is an OR type switch.
Maybe it would be useful to have a “What’s going to happen” summary before the Start button is presented.
Imagine that you didn’t write this yourself, and that you use it for a few days every few months. Would you understand the half-hidden logic of the switches and settings? Would you remember whether a switch was an AND or an OR?
It should be clear what is about to happen. It’s really not.
Rename is quite a distinct process to Match, I don’t have it enabled by default and I recomend that users first run Fix Songs without rename enabled to ensure happy with results without the extra complication of files being moved and rerun with renaming enabled if they want to reorganize their files. Actually I plan to add a separate Rename task to make this more obvious, but the thing is Rename just cares about what is in the files not how they got there.
Emptying the database empties the cache but it does not destroy data, songs with MusicBrainz Ids in the files will still have MusicBrainz Ids in them ectera. SongKong is designed so that it can work with other taggers as well , this means you could run SongKong on some files, use Jaikoz to manually identify some songs that Songkong could not auto identify, then run Fix Songs to rename everything.
I don’t understand your AND/OR view of this. If you have previously matched some songs to albums, it doesn’t really make sense to ignore them when renaming files just because they were not matched during this run. I can see why you might think Rename if Matched only applies to matched in this run, but that is not what it does.
SongKong is complex, the thing is that if you just use the defaults then it works well for most customers, the diifficulty tends to come when customers start modifying options without quite understanding what they do. But that is why we have the help and the forums to help with problems when they occur.
That sounds extremely hard to do in any meaningful way. What we do have is predefined Profiles set up to certain tasks, it also means you can create profiles and save them for reusing when you need them without having to remember exactly how they work.
If you can make the program do something, you should be able to explain it. I don’t think that it’s really that complex. It’s just a decision tree, and those can be flowcharted. The flowchart can then be condensed into a list of actions/conditions and shown to the user.
There are a limited number of goals one can have with a bunch of music files. Language in the interface should be clear and unambiguous, and the priority of one thing over another should be plain.
If there is something that says “Only”, then that should not be overridden by some other switch. Not “OR if this other switch is set”.
My understanding of the MusicBrainz DB is that it contains both song and album data.
Is it not common for people to have a directory of mixed full and partial albums? Why not match the files, hold that info in your DB, and check it against the tracklist MusicBrainz has. Then act if all of the files in the album are present, and do not act if they aren’t.
Perhaps it would be useful to set up a set of profiles that do the top 5 things people want to do, and put those in the main window popup.
Because I don’t want partial albums polluting my library. If all the files in a given album are not present, I do not want them handled in such a way as to be confusing. Only files that belong to a complete album should be renamed and/or moved.
My understanding is that “grouping” means directory, (And if not what the heck does it mean? Does it mean in the total of all files scanned in this pass?)
I think I was confused about the term “Match”. It means that there is an entry in one of the online DBs for that file, yes?. I was thinking of it in the context of the operation I was trying to perform, which is not the same thing. That’s where the “all tracks in album” thing was throwing me off, because the files were already “matched” to the DB’s— it’s not “Matched to my criteria”… See what I mean?
So, if all these files now have their ID embedded, it should be easy to look at them and perform actions if certain conditions are met. But it’s not. I can’t tell SK to gather up all the complete albums and move them to a new place. (I realize there are different album versions and releases, but choosing the first match in these cases should be right in most cases, and it’s how iTunes and XLD rip lookups work, for the most part; when there is ambiguity, a choice is offered.)
You might not think its complicated, but actually it is, users have there music organized in many different ways and often a mixture of ways within one collection and SongKong has to to deal with all of these. And users make the mistake of thinking that the way they want to do something is the one and only logical way to do something, when in fact often what they want is the complete opposite of what somebody else may want. And also users always want additional options to do things, whilst at the same time want the applications to be simpler with less option !
I can explain one option, indeed I have the problem is now not that it doesn’t work but that it doesn’t work the way you want it to work. But I cannot explain the interplay between all the options you may pick in a way that would be useful to anybody.
The option Only allow match if all songs in grouping match to one album will do just that. But the rename option Yes, if matched to release or song applies if just matched or if already matched because the idea is you can apply the rename uniformly to all your music according to rules and the metadata they have.I can see how that is slightly confusing but you had picked the wrong option anyway of Yes, if matched to release or song instead of Yes, if Matched to a Release and the difference between album and song matching is explained.
I’ve already explained this but lets give a couple of scenarios based on your idea
Scenario 1:
Scenario 2:
Scenario 3:
You just need to think of the Rename Files as separate process to Matching and that will work on the files as it is given without any knowledge of how or when they were matched. At some point in future Rename Files will be a separate top level task like Fix Songs, I may even remove renaming from Fix Songs.
This is a symptom of the problem. If there are a zillion possible outcomes, then people will wonder why the one they want isn’t included. If there are just a few, and they’re clear, then you don’t have the confusion, and people are less likely to say “Why doesn’t your car fly, too?”.
This list of possibilities shows the point of a clear, understandable outcome. If the entire process was goal-driven instead of a free-for-all, it would be easier to use and less easy to screw up.
A decision tree that we can see clearly would help SO much. Right now, the decisions are spread across different panels and the links between them and how they interact are not clear.
The main cases must be variations on a clean, organized, coherent directory structure, is that not true? It’s only the major separations that are likely to change, such as organize by Album Artist, or Genre, or Release Date or whatever—all stuff you can grab directly from the DBs, or from the files, once they have been identified.
You’ll have some stuff to solve, like orphan files, unmatchable files, etc., but you can ask directly what should be done with those.
If there were a popup of the major organizational possibilities
and a popup of the major file-naming possibilities
and a set of popup conditions to set
and all of these were visible at the same time
then the decision tree would be right there in front of the user, and it would be clear what was going to happen.
You don’t need to serve the person who wants to group all songs with the word “blue” in the title that were also released between 1970 and 1974 in the Japanese market, and have Ed Bingo on drums.
I do understand that different folks will want things organized in different ways, but what’s the point in addressing all of the weird edge cases instead of enforcing a few different typical scenarios? Risking a giant mess and a bunch of support time can’t possibly be worth it. You’ve spent more time talking to me than the fee for the software is worth, and I’m only “most” of the way to understanding what is actually happening when I press “Start”.
I’ll leave you alone now, as I think I’ve got enough of a handle on what’s going on to do what I need to do. Thank you very much for taking the time to help me.
I understand your point about being goal driven. However most customers goal is
simply for SongKong to fix my music
This concept of a flowchart is asking customers to act like a programmer, to carefully consider their existing music library and how they want it to end up, this simply is not something most customers would want to do. Take yourself as an example, you have had SongKong for quite some time, and used it on alot of music yet you hadn’t grasped the Song Only Matching or how renaming worked until now.
I don’t agree
Also its worth pointing out that what started this conversation was that you wanted SongKong to identify your random various artist songs as albums, but you didn’t want these songs to be put into album folders but left as a single folder containing many albums. That is in itself various much an edge case that nobody else has ever requested and would not be supported by the simplified decision tree idea.
Worth noting that because I support full javascript expressions in rename masks that if you do want to do this then you already can, but such complication doesn’t interfere with the way the application works.
As I say above it already does this, but this conversation started because you wanted supported for a weird edge case.
Well I have but at least because it on the forum the discussion is hopefully useful to other customers, as well as to us both so that in itself is not a problem.
However, having thought about your edge case it could still be addressed as follows:
The one possible problem here is that Undo Changes works based on looking at the music files as they were added to SongKong internal database for the first time. This database is recreated every time you install a new release of SongKong, therefore if SongKong had already run on these particular files before SongKong 7.3.1 was installed then you cannot undo those changes, only changes made since 7.3.1 was installed.
Actually, I just mentioned that it didn’t do that. I didn’t ask for it to do that. I was running tests on a folder full of mixed files, and trying to understand what would happen with different SK switches set.
I have no interest in achieving this. Was just testing, and wondering at the results.
Okay, now resolved then.
