Advice / Thoughts / Proposal - Dealing with Duplicate Tracks .02.mp3, .03.mp3 etc

I know it’s been mentioned that Picard is a verification and customizable organizing tool, not a library manager. I get that :slight_smile:

Though I still wish there were a way to keep track of what items have been saved somewhere along the line that satisfied the needs to indicate ‘complete’. But that could be a rabbit hole of it’s own. Though sort of like .bash_history, let it keep the ID of something thats been completed previously. Regardless of the quality, file formats, etc. Again, not a library manager, but as an organizing tool, giving me a way to be able to separate the already haves, (okay, semantics, call it already been run through this mill in some form or another, capice? :wink:

Like … if $HasBeen() then… which would now give a flag option for scripting these files separately. e.g., put them in a different path. So I could then have my script place them in path/tree just like incomplete, completed, and now… duplicate, or whatever the user wants to call it.

It would mean auditing against another file at processing time, if it’s used, and yes, that could mean another tick box en/disabling/clearing some file.

But it could also enhance the organizing flexibility of Picard quite a bit.

…and along those same lines, even in the same session, if it’s going to write a file that causes the need to have an incremental number appended, put those there too.

Which then brings up, I know. What about when yet an additional comes along. A 3rd, 4th, 5th… extreme examples, but it does happen when you’re trying to unscrew 20+ years of the iTunes directory ya started when it was called SoundJam.

So, on additional duplicates, do what it does otherwise does now. Appends an increment to the file name, and moves on.

Then if $HasBeen() isn’t part of the script, nothing changes. The incremented file happens in the same location as the original. If logging said file is disabled, then it would mean that $HasBeen is just ignored. Carry on as intended.

This would allow one have ‘management’ capability in the most basic form possible, while handing off the actual management to the user to decide how to deal with it.

Hey, this means I already have this, (because at some point I processed it, and have since moved it to the file tree for the music player) … and since I have this again, I can choose to ignore, compare, see if the more recent result is more preferable over what is already there… (Note I didn’t say ‘better’, that’s a user decision.) Better may mean file format, track length, or maybe ‘better’ is a crappier qualify version because you are making an example of the worse vs. the best. Who cares. Picard doesn’t.

I would imagine that at the very least, adding a variable is probably something that needs to be done in the core, in order for it to be usable in a script. Then there is that log file updating. But I’m sure there’s plenty of log files/options for log files to be updated now, so it’s not any new functionality infrastructure wise. Just another call, with another set of variables sent to some library that takes the “Do this” variable, the “This is the data” variable and writes it to the “This is the file name” variable, that itself could be hard coded just like the option of what to name cover art.

If only my scripting skills were a bit more than in the well planted range of “Enough to Get Yourself in Trouble” category. I loved flow charting in high school programming class in those days on that DEC with the neato stylish Bertone terminals. I can follow along in the code to see -what- it’s doing and document things quite well. I just step all the hell over myself trying to create from scratch and anything substantial change wise is a very in-efficient use of my time. Mostly syntax related screwups, as I do a bit better swiping bits from here and there, editing existing stuff, merging functions together.

Enough rambling on, before whoever is reading this forgets about what I first talked about / asked. :nerd_face:

Picard is not currently a library manager.

With the new version of picard released a few days ago they did add some hooks for plugins including a hook for when a file is saved.
It should be possible to write a plugin that does some library management and potentially do what you want.

One of my long term projects is to use musicbrainz collections as playlists.
You would be able to point the plugin at a publicly shared musicbrainz collection containing recordings and it will try and match this with your local collection and output a playlist.
So the first step would be to keep track of recordings saved by picard and where they are currently saved on disk.
Just don’t expect this anytime soon :slight_smile:

Have you taken a look at beets? That is a library manager and tagger.
There are plugins that can find duplicate recordings.
You can also use python to add custom tags if you need something more custom.


I actually use Beets ahead of Picard as I find it a lot more efficient for the initial clustering phase. I can feed it a whole file tree worth of whatever and get it back out sorted. I’m not afraid of the shell at all, but I will say I prefer the point and shoot method to finalize stuff. Beets isn’t as flexible when it comes to choosing things like alternate pressings right there and then. But for an automated unattended job, Beets wins hands down.

I’ll admit, I have not gotten that far into Beets plug-in and scripting wise because again, I can see things in a more visual way overall with Picard and when it comes to the fine tuning, I’ve got a lot more on the fly control over which plug-ins / options I may choose to use on a particular set of files.

Eventually it is my goal to merge a whole lot of metadata into ~35+ years of weekly radio rips. I’m pretty sure that’s going to be a Beets project. With Picard’s arsenal of options, nothing is jumping out at me that says Import Metadata to a specified track. I’ll set it up in a csv file and let it chew on it.

My goal ultimately is to get as many Dr. Demento fingerprints with their content into the MBDB, and have them locally searchable.

Now I need to peruse the docs and see how I might be able to intercept a file being incremented and saved, to point it elsewhere.

I’m not finding anything that I can tell is relevant … to being able to detect if there’s a duplicate track coming up or not, so I could tell it to switch the target directory. It kind of feels like I have to somehow do that after saving it the first time, but looking for the 02.mp3 … Hmmm…

If there’s a way to figure that out with the changes added in the 2.2 release, that is. I need to look at the plugin hooks again and see how exactly that works, if I can know what was written and do something else with it after the fact.

Here’s what I came up with as of Picard 2.2. Now to figure out how to include this on the Options window…

1 Like

If you would like to share your 35+ years let me know. Esp Dr. D. Listened to that growing up.