[Logo] (This is Old Jaikoz/SongKong forum) Please go to https://community.jthink.net
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: Focher  XML
Profile for Focher -> Messages posted by Focher [39] Go to Page: 1, 2 Next 
Author Message
Is there an option in settings to turn off the update reminders? At a certain point, we know there's an update option but if we've decided to forgo that path then are we forever to be subjected to the reminder/offer?
Works fine now. Thanks for the always fast response.
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:

 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}
 	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...

This was on OS X, by the way.

I can no longer change the field for the Base Folder in 2.3.1 as I could before.

Essentially, I want to change the Base Folder for my loaded files (I have the "MB ID Exists" filter enabled) to move them.

When I do a manual match on a track that already has a MBID set and select an entry with a different MBID, Jaikoz is not replacing the existing MBID with the new one.

Is anyone else seeing that happen?
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.

The other thread, by the way, is at http://www.jthink.net/jaikozforum/posts/list/174.page.
Minor bug in that when you do a Find and Replace, the drop down list in the dialog window that lets you limit your search to specific column shows each column name twice.

I also had my Jaikoz freeze when I tried to execute the find and replace, but I have not re-tested to see if that was a recurring issue.
For what it is worth, I am successfully running the latest release on 10.4.10 (actually on 2 iMacs - one a PPC and one an Intel in the house).

When you run this report, it now reports alls tracks missing album from all albums.

I think you guys stumbled upon a different bug.

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.

Is this a bug?
Is there a limitation of the v2.2 format in that only the MB track UID and MusicIP ID are saved?

If I tag everything, save and then re-open the files it does not have the MB ID tags (artist, release) anymore.
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.
Here is my initial idea.
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 will definitely do a screen mockup of my idea and put it here.

It seems like there is something wrong when trying to use certain images as artwork. It corrupts the color palette for the image.

I tried on both Mac OS X and Vista but experienced the same problem.

I have attached one of the jpeg files so you can see if the problem can be duplicated on your side.
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....

If you open a folder or specific files, then use the File - Close Files option, you cannot Open those files again. Jaikoz seems to think they are still open.

Only fix is to close Jaikoz and reopen it. Seems to be just a very minor bug.
I will explain my specific use case where I encountered the issue.

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.

Hope this explains it.

If I select only the record number from the record number column in the table display, the detail pane does not update with that track's data. I must select one of the fields in another column.

It would be good to have that default behavior change because it is easier when finding duplicate tracks with different bit rates.
I don't see Bit Rate anywhere as a display column option. I do see it in the Edit Tab.

Am I misunderstanding your original answer and Bit Rate is not available to display as a column?
Is there any way to select a single record and use a keyboard shortcut to delete the file? The current keyboard shortcuts take affect on all files (Delete and Undelete).

I am only able to right click and select Delete to have it flag the single record.
I was thinking of a more comprehensive workflow method that should probably be combined with the defined behavior you can define for the Auto Correct function.

Currently, you can tell Jaikoz what order to perform tasks and then it performs these tasks in sequence. For example:

1) Retrieve acoustic ID
2) Match Musicbrainz tags
3) Correct Artist
4) Correct filename

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.
I actually discovered the problem with my configuration. Apparently, my NAS is currently running Samba v2 and does not have UTF-8 support included.
I would also vote in favor of saving the acoustic id at lookup.

Perhaps an overall more flexible set of options that let's you specify which info to save automatically?
Profile for Focher -> Messages posted by Focher [39] Go to Page: 1, 2 Next 
Go to:   
Powered by JForum 2.1.6 © JForum Team