Files already tagged with MBIDs, can I add a Discogs Link?

[IvanDobsky]

After about a decade of ripping and tagging my files with Picard I have my music mostly tagged to my needs.

But I realised there is one item I would love to add.

Can SongKong and\or Jaikoz read my MBID Release tags and add the matching Discogs link to the music files?

Ideally I’d add “Discogs Release Site URL” based on what is already set via the MusicBrainz tags.

Ideally these would be sourced from the MusicBrainz page.

As bonus points I’d not want to change anything else, not even the file change date stamp.

I have been poking around the settings and don’t think I can see a way of preserving the file modified dates? I like to keep my file dates to match when it was actually ripped. A habit from the days of Winamp… Is this possible, or still not a feature?

[paultaylor]

@IvanDobsky

Can SongKong and\or Jaikoz read my MBID Release tags and add the matching Discogs link to the music files?

Hi Ivan, yes both can do that.

In SongKong simply select Fix Songs task and add all fields to the Never Modify or add these fields option on the Format tab

This will recognize existing MusicBrainz Ids so will not attempt to rematch them but just update the fields from MusicBrainz/Discogs. Because they are all fields are added to the Never Modify or add these fields option it will not modify any of them except adding a SongKong Id field and the Discogs Release Url field. Both fields (as well as MusicBrainz Id fields that you already have) are added automatically for smooth running of SongKong, that is why Discogs Release Url is not listed as a field in the Never Modify or add these fields option.

You may want to consider let SongKong add the Discogs Artist Url as well, this provides link from the MusicBrainz Release Artist to the corresponding Discogs Release Artist.

If you really wanted to remove the SongKong Id field it can be selected and deleted using the Metagrater task

SongKong wil also attempt to match any songs that dont have MusicBrainz ids. If you didn’t want this to happen then alternative would be to use Jaikoz and the Action:Remote Correct:Update from MusicBrainz this only does updates. You would also need to add the fields to the Preferences:MusicBrainz:Format:Never modify these fields option

In this case would need to not selected the Discogs Release Artist Url

Also need to add to the Preferences:Remote Correct:Discogs:Format:Never modify these fields option

@IvanDobsky

I have been poking around the settings and don’t think I can see a way of preserving the file modified dates?

We dont currenlty support that option. Not much demand there is also a technical issue, currently first time songs are processed by any SongKong task the metadata is written to internal database, subsequent processing of same song it checks to see if songkong is already in database and if so and the file modified date of file is not later than the date in database it reads metadata from database instead of file which is much quicker. This would be broken if last modified date could nt be relied on to actually indicate last modified date.

Maybe a workaround is there another tool or script you could use that would read the lastmodiified date, and write to a file, process songs in SongKong, and then read back the last modified date and write back to the file.

[IvanDobsky]

Excellent. Thanks for those details. And it is kinda how I was expecting, but you’ve made it easier with that excellent walk through. I’d keep the songkong id as I realise how useful these are to these tools, but would not want any other data changed on the initial run.

There will also be nothing without a MusicBrainz ID and matching Discogs ID. I’m a bit of a completest. It is why it has taken so long to rip everything as I am scanning all the booklets at the same time.

The trashing of the file change dates is something I’ve got to work through. After posting this question, I had read elsewhere about how this is relied on by the Jaikoz database. And understand your need. Trouble is this is a vital item for me as it is how I preserve a ripping date and how I have done things since the days of Winamp. MP3TAG and Picard being my current tools.

I’m in one of those “Sod’s Law” type situations that I have various different options in front of me, but none of them are a real solution. At this moment in time I have a spreadsheet of all my CDs with MBID and Discogs URLs in it. And my ultimate goal is getting those links not only into the audio files, but up on the KODI media player screen. So I may just be better off of bypassing the files and going straight to hacking that SQL database. Would certainly be a faster option.

I assume I can run SongKong in free demo mode to see if I can develop a touch script. I’d have to read every file’s change data in before running SongKong, then Touch all the files again after. Not exactly impossible… so still worth considering.

[paultaylor]

Hi, yes you can run all SongKong tasks n preview mode and in report see exactly what would be changed, note the report also includes a spreadsheet view.

Also Jaikoz has an export and import spreadsheet option may be useful.

But using touch idea sounds very feasible, might be an idea to also store lastmodified date as an actual metadata field in the audio files.

It would be possible tor SongKong to support last modified option, essentially if such option was enabled would need to remove song metadata from files database after run. So each time ran would read from files again with some loss of performance. I don’t like the idea that much though because it feels like hacking the filsystem, I.e modifying the files but pretending haven’t modified the files.

[IvanDobsky]

@paultaylor

I don’t like the idea that much though because it feels like hacking the filsystem, I.e modifying the files but pretending haven’t modified the files.

Well, you kind of are cheating. But it is something many music taggers have done as we see the main file as the thing file we created. That is what is important to us. So changing the tag became something to cheat. Blame Winamp in the previous century.

I’m not that odd doing this. MP3TAG and Picard also have the option built in. And KODI itself works around the lack of time stamp changes.

Its also something that has its own limitations. For example, Picard can only preserve file time stamps on local files as no control over network (i.e. SMB) stored files.

[paultaylor]

Okay, I’ve added https://jthink.atlassian.net/browse/SONGKONG-2794 tio consifder further

But what would be the disadvantage of simply storing in its own metadata field instead?

[IvanDobsky]

@paultaylor

But what would be the disadvantage of simply storing in its own metadata field instead?

It is not something any other tagger can (yet) do.

I like to have a multiple toolbox. I don’t want to commit to just one tagger app, or just one Media Player. I like to keep options open. The music files should always be portable.

The fact so many major taggers have an option to preserve file dates is really good to see. The way KODI has a way to “refresh” tag data without relying on the date is nice to see.

Your idea of embedding that rip date into the file tags is an interesting one. My own personal files come from mostly my personal CD rips, but there are a lot from “other” sources. Mostly concert bootlegs. Which is why I again like to keep their dates intact. Having a “rip creation date” in a tag is certainly something worth considering.

Sideways idea. If your Jaikoz database keeps tracks of edits by date, can’t it just keep a MD5 hash of the files instead of a date. If the hash changes then treat it like a date change.

[paultaylor]

@IvanDobsky

It is not something any other tagger can (yet) do.

I like to have a multiple toolbox. I don’t want to commit to just one tagger app, or just one Media Player. I like to keep options open. The music files should always be portable.

That is true, my thinking was that storing the date in a metadata field within the file is more portable because that information will not be lost by using tool that doesnt support/forget to activate the do not modify the last modified option, and there is not the issue you mentioned about option not working for networked files.

@IvanDobsky

The fact so many major taggers have an option to preserve file dates is really good to see.

Because my main platform is Windows its not something Ive really considered since Windows has a seperate Date Created field

@IvanDobsky

Sideways idea. If your Jaikoz database keeps tracks of edits by date, can’t it just keep a MD5 hash of the files instead of a date. If the hash changes then treat it like a date change.

So when files are loaded we can quickly read the last modified date and compare with what is stored in the database, the file contents do not need to be accessed. Unless I have misunderstood you with your idea you would have to create a md5 has of the file and then compare what is in the database, creating the hash would require accessing the file contents so would be much slower.