SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Can't replace genre, always adds. Dupe issues. Many more.

#1

I am seeing an issue where songkong will only ever add genres to the existing field instead of replacing. It adds // then the genre again. Doesnt matter which of the options to add/replace/remove I select, same behaviour.

As I only bought it to easily populate the genre field in the first place its a pain. 720 gig or so of files with a single bad field is a nightmare to sort.

Genres in general don’t seem to be handled well at all by SK. when using more than a single genre and style the text is arbitrarily added it seems.
For instance it will add “Rock; Stoner Rock” or “Stoner Rock; Rock” when using genre and style if I run the same files through twice. The fact it never replaces the field makes this a nightmare after I reran my collection through a few times.

I have ended up using songkong as a simple (if very configurable) final step file renamer and had to go back to picard to tag semi manually. A month later, 300 or so runs through SK and Picard my collection is finally back in shape except for the genres. I had decided to use a single genre and a single style, each in its own field, when I realised it wasnt replacing the tag.

Next is SKs also arbitrary duplicate handling… Just doesnt work. Doesnt even pick up a dupe if I just copy the same files into the same directory but will find dupes in an album with none. Doesnt seem to pick up on lossless over lossy. In a dir with the exact same album in say 192 and 320 it will leave a mix of both as the final result. The various options for dupe detection just give different arbitrary results.

Next is the artwork handling… Pretty much always picks the worst available art. Picard will add a perfect front cover, SK will add someones ebay picture of the LP or quite often the back sleeve rather than front.

All these and many more. As it goes I would still rate and recommend the software, especially once the genre and dupe handling is sorted, but it is very very buggy and should only be used as a final step and with a very well organised collection in the first place. Which kind of defeats the purpose. Its one single perfect feature is rollback. Having had to use it many times on the full collection I can say that part at least works 100% even with the large collection.

I’m sure a lot of the issues are with the MB and Discogs DBs themselves, but they arent issues I see with picard for instance.

Hoping the genre issue is sorted soonest, final step I need to make my collection 100%

#2

Hi, you are stating alot of problems here but none of them have been reported by anyone else so I really need some evidence to back some of these assertions up. What would be great if you run SongKong on a single folder exhibiting a particular issue and then send me your support files (Help:Create Support Files), because often the biggest issue is replicating the issue rather than fixing it.

But here are my first thoughts on what you say:

Genres:Do you have Genres:Genre set to Always Replace Value because that should replace existing values, is the problem with a particular audio format.

Duplicates:Most of the Duplicate options are based on songs Musicbrainz Ids so have you actually matched to Musicbrainz before trying to find duplicates, I honestly think you are misunderstanding the options please take a look at http://jthink.net/songkong/duplicates.jsp for more explanation.

Having found a duplicate SK decides which ones to delete and which to keep via the Advanced Options, if you have Preferred Deletion Criteria set so Audio Format is first in list and then have Preferred Audio Format set so that lossless formats at the top then it should always keep the lossless format over a lossy format. Again, if this is not the case more details please.

Artwork Handling:Since both Picard and SongKong use the same source as their Primary Artwork (Cover Art Archive) I find this very hard to believe that Picard does good matches and SongKong does nnot, additionally SongKong also uses Discogs as secondary source and only uses artwork that has been marked as being Front Cover, please give the Mb release id of a song that exhibits this behaviour.

#3

Give me a few hours and ill send the support files with all the things I bring up replicated.

Genres - Yeah, set to always replace. Did some specific testing on this this morning as it is my primary issue. This is 100% replicable. To test I have been using mp3tag to remove the tags completely then putting them through SK multiple times. Without fail the genre is appended, never replaced. Always with the // separator, not even the semi colon as is used when multiple genres/styles are requested (tested separately). As an aside, although all settings are stored between session the genre settings always reset to defaults on reload and have to be changed for every run. Not related to specific format. In testing earlier I noticed this isn’t an issue at all with the grouping field, just genre.

Duplicates - I also thought I was misunderstanding the options so I have gone over them many a time. I am using default settings as it goes. Flac and high bitrate as best. The issues I see with dupes just make no sense at all but again, are 100% replicable and have been tested a LOT, as has everything here. Thank feck for rollback :wink:

Artwork - Again, makes no sense. I can run a copy of a single album through SK then another copy of the same thing through picard and get 2 different artworks, the SK one invariably being a photograph of the LP rather than a sleeve scan. Not your fault I am guessing, something is weighting the photo over the scan, haven’t looked into this too much yet but I will replicate and send you those logs too. It doesn’t do it all the time btw, just sporadically and arbitrarily throughout the collection. Possibly related to time outs? Could I be flooding the server pushing so many requests through?

I am more than happy to test for you. Was a software tech tester for a living many moons ago (Psygnosis/Sony).

Incidentally, I am running win8.1 x64 and no itunes, saving out as id3v2.4, no v1s. Music archive is multi format, multi genre, multi release type and 60 odd thousand tracks. Playing/Library via Kodi. Have tested using specific releases as well as removing all specific release data via picard and also removing tags completely. Have run the whole collection, chunks of, individual albums and individual tracks through SK multiple times per day for over a month now. Using tag & rename, mp3tag, picard for comparison. Have tried the obvious, un/reinstall, full clear out of all data, reg entries etc. Always see the same issues.

I possibly have too much time on my hands :wink:

#4

Gmail is giving me grief over sending the support file zip, too large to attach, so I’ll come back to that later when I have time.

In the mean time check out MBz ID bbc5ad2c-a69b-426b-b8e3-416da4b4a00f as an example of the artwork problem, album is Alabama Thunderpussy - River City Revival.

SK always grabs cover art for that that is someones photo of a promo CD in a drive tray. All other software, picard for instance, gets a scan of the cover.

My mp3 rip is not from a promo, is from my own retail CD.

#5

Please use something like Dropbox instead

Or you can minimize your logs and reports by running Help:Empty Log Files and then Help:Delete Reports , then do your test, then create report.

I have looked at http://musicbrainz.org/release/bbc5ad2c-a69b-426b-b8e3-416da4b4a00f now although MusicBrainz shows artwork , that artwork is from Amazon and that artwork is not readily available. MusicBrainz website can use Amazon artwork because they have a link to the Amazon buy button, but we can only use Amazon artwork if the name of the Amazon image is based on the Amazon Id which this one is not. There is no artwork available from Cover Art Archive.

But the MusicBrainz release does link to this Discogs release http://www.discogs.com/release/1362142 which also has artwork, unfortunately this artwork is of type Secondary not Primary, all front cover art from Discogs should be set to primary so this is ignored.

But we then look at Discogs releases within the same grouping and look for primary artwork there, and find some for http://www.discogs.com/release/2178184 - unfortunately this shouldn’t be marked as primary but because it is this is what we use.

Im not sure what Picard does in this case.

I’m not sure what I can do in this case, but I will investigate if there is an issue with how Discogs marks cover art as primary. Bu this still seems like a rare case to me rather than Pretty much always picks the worst available art

#6

Okay I think the secondary/primary distinction is basically now defunct on Discogs so Im going to start allowing secondary images, this should resolve the issue. This fix can occur purely on the Jthink Music Server so you should see improvements once its fixed without needing a new version of SongKong.

#7

I tried to replicate the genre problem and not seeing any issue, genres are replaced. I wonder if its a format specific format, what format are your files in (e.g mp3, mp4, flac)

#8

Re artwork, server is fixed but requires a change on client after all to access secondary images, can track issue with http://jthink.net:8081/browse/SONGKONG-808 and http://jthink.net:8081/browse/JAIKOZ-965

#9

OK did a bit more testing over the weekend and discovered a few things.

The artwork issue… To clarify, it pretty much always picks the wrong art when I am attempting to retag stuff that already has wrong art. This is where it becomes arbitrary. Sometimes finding correct art but usually not while picard and others have no issue. Im obviously not tagging stuff that is already perfectly tagged.

The genres issue seems to be m4a specific. I wasn’t aware just how many m4a files I had until this brought it up, so it has been quite useful ironically. Replaced most with mp3 and flac. So the issue is moot to me now but still appears to be a bug.
I also cant say how often the genres settings resetting themselves has influenced this, but that in itself is a bug.

Duplicates - Seems to be giving priority to tags in making its decision. The same file with and without a tag is not picked up as dupe.
Havent tested this much as I dont trust it so I just dont use it. Picard sorted any dupe issues I had.

In the process of reformatting my server so I will test again on a vanilla setup and get fresh logs to you asap.

#10

\t

Ah okay this fits in with what I discovered, these releases probably do not have primary Discogs artwork so I have been looking for similar releases as that is all I have. But soon i can check for secondary artwork on these Discogs releases before looking at similar releases, this should be much better. (As far as I can see Discogs releases with only secondary images and no primary image is a bug in Discogs itself, but not one they are unlikely to fix ant time soon).

Sounds possible, I’ll take a look in a minute.

By tag do you mean metafields such as title or artist ?

I think you simply have the Delete Duplicates/Standard/Delete Duplicates if has the same set to Same song and album (metadata only) This is the default because it is one of only two options that will work before running Fix Songs (because it does not rely on your songs having Acoustids, Musicbrainz ids) , but it isn’t the recommended option. You should get warning if you run Delete Duplicates with this option but I’'ll double check.

Note you can run Delete Duplicates in preview mode so that it makes no actual changes

#11

By tag I mean the whole tag. If I completely remove the whole tag from an album then put the files with no tag back in with the tagged files they aren’t always picked up as straight dupes, I haven’t spotted a pattern to this yet. The same file with and without the 2 second gap is also not spotted as a dupe. The same album in flac and mp3 often isn’t picked up as the same and when it is will leave an album that is a mix of both.

I have tested this using each of the available detection methods getting different results in each. To be fair though, I haven’t tested it a lot.
All modes seem to have an issue with untitled songs too, deleting them seemingly randomly. Minor issue, but it crops up a fair bit over the course of the whole collection. It tags them as [untitled].mp3 for instance, then in a dupe run will delete randomly or all but the first.
The best example of this I can think of at the mo is with 93dd4f00-5098-4e65-afe0-a08de390d35b, a.P.A.t.T. - (L.P.), which has about 55 untitled 4 sec identical silent tracks before a final proper track. On a dupe run using each of the available methods deletes various of the untitled tracks or all of them, including the 31 minute final track.

Preview mode is only any use with small numbers of files, I go text blind after the first few thousand.
Speaking of which, is there any chance of adding an option to run the task in preview mode but then make the changes live if the results are satisfactory?

#12

[quote=madmuhfuh]By tag I mean the whole tag. If I completely remove the whole tag from an album then put the files with no tag back in with the tagged files they aren’t always picked up as straight dupes,
[/quote]
Okay I think if you could get me some suport files that would really help as clearly easier for me to decode the reports and logs then you

Okay that is a pretty extreme edge case not the usual scenario, but again without seeing your reports hard to comment further.

[quote=madmuhfuh]
Speaking of which, is there any chance of adding an option to run the task in preview mode but then make the changes live if the results are satisfactory?[/quote]
Yes we have

http://jthink.net:8081/browse/SONGKONG-742

and

http://jthink.net:8081/browse/SONGKONG-167

#13

Okay, server reformatted, SK reinstalled, everything at defaults. Tried a dupe run, same album, 320 original and 192 downsampled versions. Worked perfectly when set to sounds the same only, none of the musicbrainz based detections worked. When I looked at the tags it had tagged the duplicate as a different version of the same LP so that explains why the MBz based detections didnt work, but not why they were tagged like that in the first place or why it saw it as complete with a track missing, I had tagged set to only allow if complete. Support files are inbound anyway.

Question re “sounds the same”, will that differentiate between a recorded and say a live or demo version of the same track? And does it only detect dupes within a single cluster/folder or throughout an artist or collection?

#14

[quote=madmuhfuh]Okay, server reformatted, SK reinstalled, everything at defaults. Tried a dupe run, same album, 320 original and 192 downsampled versions. Worked perfectly when set to sounds the same only, none of the musicbrainz based detections worked. When I looked at the tags it had tagged the duplicate as a different version of the same LP so that explains why the MBz based detections didnt work, but not why they were tagged like that in the first place or why it saw it as complete with a track missing, I had tagged set to only allow if complete. Support files are inbound anyway.
[/quote]
Okay Ill take a look at the support files when I have them before commenting.

Yes usually, although the Acoustid/Musicbrainz databases are not 100% perfect so you can protect further against incorrectly finding duplicates when they are different songs by using Same MusicBrainz Song and sounds the same

[quote=madmuhfuh]
And does it only detect dupes within a single cluster/folder or throughout an artist or collection?[/quote]
It detects throughout the top level folder you selected when you started Delete Duplicates.

#15

Just wanted to say for the record, you give by far the best support I’ve had for a piece of software. Worth every penny and more. Bugs are to be expected, support usually isn’t.

Thanks man :slight_smile:

#16

[quote=madmuhfuh]Just wanted to say for the record, you give by far the best support I’ve had for a piece of software. Worth every penny and more. Bugs are to be expected, support usually isn’t.

Thanks man :)[/quote]

Thankyou, I’m striving to create some great software and I think one of the best ways to achieve that is through listening and engaging with customers thats why I have user forums and a public bug tracker.

#17

Okay, so Ive been looking at the genre issue

First of I found this bug in the Gui http://jthink.net:8081/browse/SONGKONG-811

The value of Fix Songs/Genre/Genre is set to the index of value of Fix Songs/Grouping/Grouping from value

So if:
Grouping from set to
Discogs Style, then Genre set to Always Replace Value
Discogs Genre, then Genre set to Always Add Value
Discogs Styles and Genre, then Genre set to Replace If Empty

So this may be part of the problem, not sure but anyway its now fixed for next release.

Secondly there are a couple of issues specific to Mp4. Actually although Jaikoz and SongKong can write multiple genre fields they will only look at the first genre field when reading the file and when writing a new genre old ones are not always being deleted see http://jthink.net:8081/browse/SONGKONG-813

Mp4s actually contain two fields for writing genres depending on whether the genre is a known standard genre or not and I think the issue is that SongKong is only deleting from the genre field not the @gen field and so a new @gen fields (atoms in mp4 parlance) is being written each time.

You could confirm this by looking at your file with http://atomicparsley.sourceforge.net/

#18

http://jthink.net:8081/browse/SONGKONG-813 now fixed for next release.

#19

I haven’t received any support files yet, did you send them to support@jthink.net ?

#20

Any issues identified in this post were fixed in either SongKong 3.9 or the newly released SongKong 3.10.