I am getting this for a lot of entries, but don't see the null part of the message. It's happening on plain mp3 files for me. And these aren't strange tracks. For example, on mainstream U2 releases I get it.

From the log:
Code:

09/08/2008 09.55.26:com.jthink.jaikoz.manipulate.ManualCorrectFromMusicBrainz$WorkerReadThread:analyse:SEVERE: There was a problem submitting a query to MusicBrainz for Record Number 26 with filename U2-Rattle And Hum-08-Silver And Gold Live.mp3: {2}
java.lang.NullPointerException
at com.jthink.jaikoz.manipulate.MusicBrainzRESTQuery.calculateUnnormalisedNumberOfTracksInAlbum(MusicBrainzRESTQuery.java:1707)
at com.jthink.jaikoz.manipulate.MusicBrainzRESTQuery.calculateUnnormalisedAlbum(MusicBrainzRESTQuery.java:1813)
at com.jthink.jaikoz.manipulate.MusicBrainzRESTQuery.calculateUnnormalisedScore(MusicBrainzRESTQuery.java:2067)
at com.jthink.jaikoz.manipulate.musicbrainzhelper.TrackWithUnnormalizationScore.<init>(TrackWithUnnormalizationScore.java:24)
at com.jthink.jaikoz.manipulate.ManualCorrectFromMusicBrainz$WorkerReadThread.analyse(ManualCorrectFromMusicBrainz.java:354)
at com.jthink.jaikoz.manipulate.ManualCorrectFromMusicBrainz$WorkerThread.run(ManualCorrectFromMusicBrainz.java:290)

Just for the record, my experience with this problem went away. I know I had closed Jaikoz and reopened it without solving the problem initially, but I am not experiencing it now (without any updates). Maybe I rebooted...

I think I covered my view on the Manual lookup option in the other thread along with a gui mockup so won't rehash any of that other than to say that the main shortcoming I have found in the Manual Match process is that I often end up matching PUIDs from different release entries in the MB database.

Granted, a lot of times this is because there are duplicates in the MB database, but at least showing the MB Release Id would allow the user to easily match up to the same release entries.

Regarding what I experienced, I am able to consistently reproduce the problem I initially mentioned in this thread.

Create a folder with multiple sub folders containing tracks. Open Jaikoz and do a File - Add Files of this top folder. Make sure you include sub folders in the scan.

Jaikoz will open all the files just fine. Now do a File - Close Files. Everything closes fine.

Without exiting Jaikoz, do an Add Files again and choose only one of the sub folders. Jaikoz will report that you already have the parent folder open and that you cannot open files twice even though you closed the files.

My ultimate goal would be to get access to the internal IDs, especially from other track records on the same album, in a more comprehensive way on the screen to help better select the right MB ID for the track.

I'm not so sure I agree that casual users wouldn't also benefit from this. While I cannot obviously speak for anyone but myself, the main reason I bet most people select Jaikoz over other tagging software is the thorough MusicIP and MusicBrainz integration. So being sure to match the IDs properly would be of use for many users, I think.

Regardless, I would see it as an improved replacement for the Manual Tag from MB function. It has all the same information (adding the additional columns like track #, length, etc is easy enough with that layout) plus the benefit of better album ID matching.

I also think this interface could be an improvement for usability in regards to the batch queries. It becomes less important to do large batches if you basically have a queue of 20 or 30 queries in memory and the program queries ahead of the user's involvement with selecting tracks.

I agree that there needs to be an improved way to copy and paste certain fields across records. For example, all the fields that show under the MusicBrainz tab in the detail view should be settable as a column for easy copy and paste. I think Paul is reworking that if I have read some other postings correctly. This would basically let you set the ASIN field as a column and then copy and paste down to multiple records.

In the meantime, I actually just save the artwork as a jpg on my machine then add it to the first track. Then I can copy and paste the artwork down to multiple tracks. Agreed it is an additional step and leaves you with the jpg on your machine, but overall workable for now.

I have noticed that quite often the first track of an album which is already marked as track "1" will fail in the MB lookup but the rest of the tracks proceed fine. It happens enough that it makes me suspect there might be a small bug where this happens under very limited circumstances.

Is anyone else seeing this kind of behavior? Or is it purely my imagination?

There must be something uncommon in the JPEGs that show this problem. I "solved" the problem by opening them in the OS X Preview function and then just doing a save. After that, I could add them without the palette corruption.

I reattached the exact same JPEG as before but after I opened it and saved it.

I am pasting the MB UID from the MB entry with the same MB Album Release ID (sometimes there are duplicate album entries with different MB UIDs for the tracks).

The problem with this method is that it is very cumbersome because the MB website makes you drill down to each individual track to get the UID to copy and paste. So if you have multiple tracks with the "wrong" UID that doesn't match for that particular album ID, you have to navigate through quite a few screens plus the swapping back and forth between the browser and Jaikoz.

I do sometimes have to do this but it is really a rather cumbersome process. Usually, the need only comes up when I have Jaikoz do an autocorrect tags from MB after the acoustic id has been updated. This often causes a mixture of tracks from different album entries in the MB database.

The way I typically fix it is to bring up the Album on MB and manually copy the MB Unique Id to the track as you recommend.

Again, it would be nice if there was a faster way to do this. Perhaps displaying the MB Album Id in the window when using the Manual select method from MB. In fact, it could be better to display each track independently for the user input to select which one to use. Then you would have a lot more screen space to display all the information that is both also in the tags plus the MB data that the user might want to use to select the best entry. Once the MB entry is selected, just display the next track's info.

When I use the option to manually select the MusicBrainz UID for a given track, I am often surprised that I do not see the track listed even though I have specifically pre-populated the MusicBrainz Release Id field. It seems that when doing a query from the MB database, having a match on the Release Id and a matching name on the track name would almost automatically give the entry a pretty high score and show it in my list. But it doesn't.

Is this working as designed? Can you give us an idea as to how the MB queries are done (what is queried, what order) and then how those queries are scored?

In the long run, I think it would be great if we could customize that process. In the long run....

I want to restrict the table view to show only duplicates by either MusicIP or MusicbrainzID. I then want to delete each duplicate but want to delete the lower quality one (e.g. lower bit rate). In a best case scenario, I could show the bit rate in the table view for each row. However, I cannot seem to do that as designed. The bit rate is viewable, however, in the Detail Pane. So I was hoping that when I click on the record number for each row, the Detail Pane would update to show me the track details, including bit rate.

The best case scenario is that I would be able to see the bit rate in the Table View. Having the Detail Pane update when click on the Row header number is just a workaround.

I would change two things. First, I would add a "Save" action that could be added at any step of the way - you could even have it save after every task if you wanted to. Second, I would allow the user to change the behavior so that instead of performing the tasks on all files before moving to the next task, allow the user to specify that those tasks run in sequence per file.

I guess I don't see the risk there if you handle duplicate files the same way you currently do (append a number to the name).

I was thinking that you could just choose which attributes force a save of the update. This would be good for us who are willing to take the risk of a somewhat automated mass update and save the time of waiting for a file save / directory reorg at the end of the process.

How about a section in the report that lists separately all of the complete albums? This would make it easier to move those sets of files out of the "checking" process as completed.

Or the alternative is to offer a completely separate report of Complete Albums. I don't actually like that alternative because from a procedural standpoint, Jaikoz has to do exactly the same about of lookups to make such a determination anyway.