[Logo] Jaikoz and SongKong Forums
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: jdoering  XML
Profile for jdoering -> Messages posted by jdoering [20]
Author Message
Well clearly this is a beta version; but the move (dropping support for calculating PUIDs) looks pretty aggressive if Picard via the Acoustid author doesn't even directly support the new scheme yet and is still worried about fingerprinting more collections of known content (http://forums.musicbrainz.org/viewtopic.php?pid=15236#p15236).

Maybe licensing made it impossible to continue right now? Too bad since it looks like a strong migration timeframe would be ideal (and full support for both mechanisms should be maintained during that timeframe).

Based on the original MusicBrainz announcement when they licensed with MusicIP they were suppose to be able to continue the service (http://blog.musicbrainz.org/?p=160) even if MusicIP stopped providing it. Maybe that didn't cover the licenses needed for third party apps? Otherwise it looks like they're falling into the exact trap they indicated back then shouldn't be possible.

Anyway; I'm all in favor of a new open system that won't be plagued by these issues. But it looks like right now PUIDs will still have a decided advantage in linking to existing MusicBrainz data. Dropping it from Jaikoz already means I'll again have to pull additional tools (Picard likely or genpuid.exe directly) which is a pain to say the least and diminishes the one-stop advantage of Jaikoz.

-Jeff
1) Will this guaranteed delete everything (tags Jaikoz doesn't understand, etc)?

2) How will this preserve MBID + PUID? I don't want to have to rely on file renaming to preserve the MBID (which is an ugly hack I'm using right now).

I guess part of my concern is that it wasn't obvious to me that selecting and delete all would wipe out everything. Wouldn't that be limited to what's currently visible in the GUI?

-Jeff
I was going to start a new thread on a very similar feature request. This request is similar enough that I'll start the discussion here.

I have a variety of music files laying about that have mucked up tags for a variety of reasons (bugs in various rippers, taggers, etc + me messing things up over time, etc). I'd like to be able to use the existing tags to assist in proper MB identification but then discard everything existing and only keep the new data fresh from MB.

My problem with the current features (as I understand them anyway) is that the MB data only overwrites some tags. I want to automatically clear and start over including both tags Jaikoz does and does not understand (so specifically remove the entire existing tag structure rather than tag by tag modification).

I'm currently accomplishing this trough a painful process. Identify correclty in Jaikoz and rename the files to a "MBID-PUID" pattern. Then use the "tag" program http://www.synthetic-soul.co.uk/tag/ to remove all tags from FLAC + MP3 files. Finally; re-tag in Jaikoz by parsing the MBID + PUID from the filename. Correct all data from MB and then rename the files back to a sensible pattern.

Obviously this is a bit cumbersome. I'd love a single option in Jaikoz to Wipe Existing Tags and Retag from MBID. Perhaps the set of tags to preserve (MBID, PUID, possibly cover art) should be configurable.

Of course if there's already a good way to accomplish this in a bulk fashion with Jaikoz; I'd love to hear it.

-Jeff
The match release flow isn't changing any already set tags. It's just filling in some missing ones. Specifically the release event related tags: release date, country, label, and media. Barcode and cat no have no data at MusicBrainz for this particular release.

Send additional detailed info via e-mail to clarify the issue.

-Jeff
Clearing the cache did not help. I produced a level 7 logfile and sent that and the track I mentioned to Paul. Hopefully this will clarify the problem.

-Jeff
I picked the shortest track that did have a PUID (so the file would be small if I sent it in). The same thing happens with all of the tracks on the album (one is too short for a PUID and the rest are "normal" length).

I'll send the details in.

-Jeff
It's definitely not picking a new release; I triple checked. All of the existing MusicBrainz fields (DiscId, ReleaseId, etc) that were filled in by the update step stay the same during the match release step. The only change is that some additional release-specific fields are populated.

I can reproduce the issue with a single 500Kb song from my album. Maybe I have something strange in my settings although nothing jumps out at me. The MusicBrainz settings for the impacted fields are all set to "Always replace value".

Here are the MusicBrainzId (4e4b66b2-6ea6-4c5f-9622-dee1ad8ed273) and PUID (248d8ed2-7dd2-ad3c-1577-ab5da4e1fb8c) that I start with. It's a 22 second mp3 track initially with no tags at all. That track id corresponds to MusicBrainz release Id: 056d82e5-cdd3-4548-9bbd-d5b7f599340f.

I can provide the actual track via e-mail if that helps narrow down the issue.

-Jeff
I'm trying to clean up tags on a bunch of my files. To accomplish this I first named all of my files as MusicBrainzID-PUID. Then I used a separate program to clear all tags (nicely removes ID3 tags from FLAC, etc). This allowed me to clear everything out without losing my identification.

I then opened the files in Jaikoz and used "Correct Metadata from Filename" to get my MusicBrainz-PUID back (one glitch there; files too short for a PUID had to be processed a second time with a different pattern rule).

I thought that after this step that "Update Metadata from Existing MusicBrainz Id" would bring in everything available from MusicBrainz. While it did fix Title/Album/Artist, etc - it left several of the release related fields blank (e.g. year, barcode, cat no, label).

I can get the missing fields to fill in by selecting all songs for a single release and choosing "Match songs to one MusicBrainz release". This fills in all of the missing release related fields WITHOUT actually changing the MusicBrainz release Id at all.

This seems like a bug as I cannot imagine why updating metadata from existing MusicBrainz Id wouldn't bring in everything possible compared to the match to release flow given that the ids don't change at all.

While I have a workaround; it is very inconvenient as I have to do it one album at a time rather than for my entire collection.

-Jeff
I'll have to try these options out. I was pulling my hair out trying to deal with the default behaviors. In particular; I'm trying to get accurate tagging to use with Squeezebox Server. Even when Musicbrainz release ID is set it still considered two songs to be from different albums if their DiscNo/DiscTotal tags don't match. So 1/1 is not the same ablum as unset/unset. This seems a bit picky but reasonable if tagging is correct.

I was getting releases where some tracks had different values for the DiscNo/DiscTotal fields even though they all matched a single Musicbrainz release. It took me a while to figure out that automatic Discogs matching created this situation when some tracks match to Discogs and others don't (because Discogs did not have a release that matched exactly to the newer Musicbrainz release).

It looks like these additional options will give me the finer control I need to avoid this mess.

On a separate note I'm not sure that I totally understand Jaikoz's behavior in terms of the DiscNo/DiscTotal field. Why fill it in all the time for Discogs but generally leave it blank for one-disc releases from Musicbrainz? It would seem reasonable to always fill it in an avoid ambiguity. Or maybe the behavior is more complicated that I just stated and depends on more details of the MB/Discogs metadata?

BTW I'm using 3.8.3 but posted here since this thread directly addressed the features I'm looking at.

-Jeff
I'm having problems using rename sub-folders from tags for an ablums that ends with "..." using the pattern "%H%Z%B".

Trailing dots are apparently not generally legal for Windows folders. Commands like mkdir implicitly trim them off and succeed. I did manage to create some with mkdir using weird backslash syntax, etc. But then cmd.exe, explorer, etc can't even access or delete the directory right (now I need to find a tool that can delete them).

Jaikoz appears to handle a single trailing dot semi-incorrectly and multiple trailing dots is fatal.

For the single dot case "SomeAlbumName."; the save operation succeeds although the actual directory created is "SomeAlbumName" with no dot. Everything seems fine unless you re-load the file and rerun correct sub-folders from tags. Jaikoz thinks the file needs updating to fix the missing "." (unlike other illegal filename characters which Jaikoz seems to properly exclude when correcting sub-dir from tags).

The multiple dot case "SomeAlbumName.." is fatal as the initial save itself fails on the rename operation. A directory with no trailing dots is created; but Jaikoz fails to move the file at all and leaves the file marked as changed.

Based on a few simple tests; interleaving spaces and periods at the end of a file causes the same problem. It appears periods need to be treated as whitespace and trimmed off of the end of directory names.

Correcting the filename from tags does not have this issue as the ".mp3" file extension provides safety for trailing whitespace in the base filename.

Rather than corrupting my tags; it looks like I'll have to temporarily use a pattern like "%H%Z%B-" to work around the issue.

Thanks,
Jeff
Does Jaikoz have an equivalent of this MusicBrainz Picard feature?

Some of my tracks are now named using foreign characters since retagging by Jaikoz. This is not very useful to me and causes issues with tag encodings (since the nice charset-safe options like UTF-8, etc all seem to cause compatibility problems with various applications).

-Jeff
Thanks! Works perfectly now...

-Jeff
I'm running into an unexpected error trying to correct sub-folder from tags.

BTW great enhancement list in the last release!

-Jeff

Here are the log contents:

User Log:

Feb 1, 2008 1:31:11 PM: INFO: Jaikoz v2.2.0 using Java 1.6.0_03 on Windows Vista initialized successfully
Feb 1, 2008 1:31:49 PM: INFO: Started to load files from U:\Music\Jaikoz-Processed-Lost
Feb 1, 2008 1:31:52 PM: INFO: Counted 74 files that could be loaded from U:\Music\Jaikoz-Processed-Lost
Feb 1, 2008 1:31:52 PM: INFO: Completed loading of 74 files from U:\Music\Jaikoz-Processed-Lost
Feb 1, 2008 1:32:24 PM: SEVERE: Unexpected Problem with Jaikoz please report problem to support@jthink.net
Feb 1, 2008 1:32:24 PM: SEVERE: Trying to map column options for illegal index:4


Debug Log:

01/02/2008 13.32.21:com.jthink.jaikoz.EventDispatchThreadExceptionHandler:handle:SEVERE: Uncaught throwable caught by EventDispatchThreadExceptionHandler:Trying to map column options for illegal index:4
java.lang.RuntimeException: Trying to map column options for illegal index:4
at com.jthink.jaikoz.manipulate.autoformat.MapColumnOptionsFromIndex.convertIndextoColumnOptions(MapColumnOptionsFromIndex.java:65)
at com.jthink.jaikoz.manipulate.AutoMatchProperties.applyPreferences(AutoMatchProperties.java:95)
at com.jthink.jaikoz.manipulate.AutoMatchProperties.<init>(AutoMatchProperties.java:75)
at com.jthink.jaikoz.manipulate.AutoMatchProperties.getInstanceOf(AutoMatchProperties.java:8
at com.jthink.jaikoz.manipulate.ColumnAnalyser.<init>(ColumnAnalyser.java:117)
at com.jthink.jaikoz.manipulate.ColumnAnalyser.<init>(ColumnAnalyser.java:90)
at com.jthink.jaikoz.manipulate.DirectoryAnalyser.<init>(DirectoryAnalyser.java:44)
at com.jthink.jaikoz.action.CorrectSubDirectoryFromTagsAction.actionPerformed(CorrectSubDirectoryFromTagsAction.java:49)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
01/02/2008 13.32.21:com.jthink.jaikoz.EventDispatchThreadExceptionHandler:handle:SEVERE: RuntimeException occurred in application
java.lang.RuntimeException: Trying to map column options for illegal index:4
at com.jthink.jaikoz.manipulate.autoformat.MapColumnOptionsFromIndex.convertIndextoColumnOptions(MapColumnOptionsFromIndex.java:65)
at com.jthink.jaikoz.manipulate.AutoMatchProperties.applyPreferences(AutoMatchProperties.java:95)
at com.jthink.jaikoz.manipulate.AutoMatchProperties.<init>(AutoMatchProperties.java:75)
at com.jthink.jaikoz.manipulate.AutoMatchProperties.getInstanceOf(AutoMatchProperties.java:8
at com.jthink.jaikoz.manipulate.ColumnAnalyser.<init>(ColumnAnalyser.java:117)
at com.jthink.jaikoz.manipulate.ColumnAnalyser.<init>(ColumnAnalyser.java:90)
at com.jthink.jaikoz.manipulate.DirectoryAnalyser.<init>(DirectoryAnalyser.java:44)
at com.jthink.jaikoz.action.CorrectSubDirectoryFromTagsAction.actionPerformed(CorrectSubDirectoryFromTagsAction.java:49)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Another vote in favor of this feature; although I don't see any response as to whether it is likely, possible, etc.

I was unpleasantly suprised when I used search from Windows to find a set of files (spread around for no good reason; that's part of what I was trying to clean up) and then couldn't drag-and-drop them directly into Jaikoz to work on their tags. They didn't exist in a single directory and adding them to Jaikoz one by one was tedious.

While I love the features of Jaikoz; I think it's the kind of tool that has the most value when it can be used seemlessly with other familiar tools to solve file management issues (since it never seems like any one tool is best-of-breed at handling all of the different strange file management issues that crop up).

Thanks,
Jeff
That's going to show me all four files. I should have given a more complete example:

File 1: ID = XYZ, PUID = 123
File 2: ID = ABC, PUID = 456
File 3: ID = XYZ, PUID = 789
File 4: ID = ABC, PUID = 345
File 5: ID = XYZ,PUID = 789

I want to only see Files 3 & 5; I'll pretty blindly delete one of them. I want to look more closely at files 1,2, & 4 in a separate filtering pass since the difference in PUID<->MB-ID mapping warrants further investigation to account for possible earlier tagging mistakes, etc.

Yes, a corner case I did just create files with the pattern above and the combined use of both duplicate filters results in all five files being display. So the filters are consider independently as I expected.

-Jeff
Definitely an MB/MusicIP geek feature Again, thanks for the quick feedback.
Thanks for the feedback.

I may be over-thinking a corner case but the MB-ID+PUID duplication scenario I imagined was to distinguish the combined case from independent duplication of the individual tags. E.g.

File 1: ID = XYZ, PUID = 123
File 2: ID = ABC, PUID = 456
File 3: ID = XYZ, PUID = 789
File 4: ID = ABC, PUID = 345

Strange case; but I believe it's possible in my collection to have two albums that should have a PUID-collision (because different albums had a duplicate song) but then I have MB-ID collision with non-matching PUID as well (duplicate song from same album but not really from same original so PUID mismatch).

This is different from MB-ID+PUID match which is very really strong indication of a duplicate with no need for additional checking before delete.

Again, yes probably a corner case - I can use the combined filter approach and manually check for the special-case of MB-ID+PUID matches.

-Jeff
I've just started using this (great) tool. I've also read a bunch of the posts on here with regard to manual MB correction, etc. However, I can't tell if there's a supported way to do what I want (I don't think there is).

I'm trying to verify existing tagged files with both PUIDs and MB Unique IDs. Because the Unique IDs may not have been written at the same time as the PUIDs; I want to know whether or not the mappings match MB data.

I don't want to use the manual flow as that would require me to look at each record; I'm not interested in records where the mapping exists in MB.

I don't think the automatic flow is doing what I want as I believe it is sometimes suggesting changes to the MB Unique IDs even when the mapping does exist (either because some other match criteria have a higher weighting due to factors other than the PUID or equal "100" ratings getting prioritized by order returned or something).

So basically I want to auto-flag all MB-ID<->PUID mappings that do not exist in MB without considering any other data about the track. I'd then perform manual MB correction on those tracks only (and possible end up submitting new mappings to MB in the process I believe).

Am I missing something that can be accomplished with current features?

One related feature I'd like is to be able to detect duplicates based on MB-ID+PUID; this would provide a little more assurance of true duplication for first-pass deletion. MB-ID duplicates with PUID mismatches would warrant a bit more inspection for incorrect MB-ID, etc.

-Jeff
How about an option to suppress the -noanalysis option being passed to genpuid?

For most tracks with an existing MusicIP fingerprint the PUID would just come back right away; but then for tracks with no existing fingerprint the analysis would get submitted to MusicIP upfront (at a much longer processing time of course).

I'm thinking of using a wrapper executable to strip the option and pass the rest to the real genpuid; but obviously that's a clumsy approach (I tried patching the genpuid binary to change the argument name but then it chokes due to an unrecognized arg - it won't ignore).

-Jeff
Hmm... I've just started using the program so I'm not clear on all of the options; but I'd like exactly the opposite to some degree.

When I have a bunch of individuals songs from an artist but nowhere near full albums; I'd prefer a "minimize albums" option (which would favor compilations).

Just a thought... I've been doing it manually with MB Picard to some degree.
 
Profile for jdoering -> Messages posted by jdoering [20]
Go to:   
Powered by JForum 2.1.6 © JForum Team