Jaikoz v2.3.0 released with automtaic lookup of lyrics and drag and drop support, plus a number of bug fixes and small enhancements
For more details see
http://www.jthink.net/jaikoz/jsp/news/build1043.jsp
Jaikoz v2.3.0 released with AutoCorrect Lyrics and Drag and Drop
Great job with the lyrics! Do you know that 3 -5 lyrics are using additional 1k RAM?
The behaviour of memory usage at all is still the same. Are here other users using Jaikoz on Vista? Maybe it’s a problem at the OS.
Good job paul! Working like a charm here! 
Same for me. Great job! This is the best lyrics retriever I’ve seen.
Could you please confirm that Jaikoz will write these lyrics as ISO-8859-1 if my Save options are like the attached screen shot? Lyrics look fine in iTunes, but are unreadable in another app which has trouble with encoding other than ISO-8859-1.
Shortly after starting to play with lyric download & editing, I received severe errors, logs also attached. Any ideas?
WHAT I WAS DOING: In an attempt to correct the apparent text encoding incompatibilities described above, I tried to “remove whitespace” and “remove widespace” after downloading lyrics (right-click on lyrics cells). I also tried to manually edit the trailing whitespace (consistently several empty carriage returns visible only in the lyrics tab of the Details pane) in the downloaded lyrics since removing white/wide spaces didn’t seem to do this, as I expected after reading the Offline Help.
[quote=GiacomoGo]Could you please confirm that Jaikoz will write these lyrics as ISO-8859-1 if my Save options are like the attached screen shot? Lyrics look fine in iTunes, but are unreadable in another app which has trouble with encoding other than ISO-8859-1.
[/quote]
Actually it will use IS0-8859-1 by default but if there are values that cant be encoded in ISO-8859-1 it will use UTF-16, this is the only other supported encoding in ID3v23. If you really dont want to to use this you would have to remove characters that cant be encoded from the field, and also make sure ‘Save existing fields using these preferences’ is checked to rewrite fields that already existed in the file.
I’ll have to get back to you on the subsequent errors.
Thanks, Paul. Could you please confirm whether Jaikoz is inserting some UTF-16-only character(s) in the USLT header? The reason I ask is that my non-UTF app displays strange leading characters that I have no control over (see screenshot & mp3, attached – the lyrics start “Ice age heat wave …”). As I read the id3v2.3 specs, these unfamiliar chars seem to come from the USLT “content descriptor” header byte(s), but I can’t control this descriptor.
Also please feel free to move this thread to an appropriate spot in the forum.
===
Actually I get a consistent error when I try to attach the sample mp3 – or any second attachment like a screenshot of the Apache error – so instead, I’ve loaded the mp3-sample here: …/sample.mp3
Here’s the Apache error:
java.lang.NullPointerException
\tnet.jforum.JForumExecutionContext.enableRollback(JForumExecutionContext.java:272)
\tnet.jforum.JForum.service(JForum.java:209)
\tjavax.servlet.http.HttpServlet.service(HttpServlet.java:802)
\tnet.jforum.util.legacy.clickstream.ClickstreamFilter.doFilter(ClickstreamFilter.java:59)
[quote=GiacomoGo]Thanks, Paul. Could you please confirm whether Jaikoz is inserting some UTF-16-only character(s) in the USLT header? The reason I ask is that my non-UTF app displays strange leading characters that I have no control over (see screenshot & mp3, attached – the lyrics start “Ice age heat wave …”). As I read the id3v2.3 specs, these unfamiliar chars seem to come from the USLT “content descriptor” header byte(s), but I can’t control this descriptor.
[/quote]
If the lyric itself is in UTF16 the content descriptor should be as well, but in this file it looks like its sort of corrupted but I cant get Jaikoz to do this, are you sure the file wasnt already like it.
Jaikoz inserts an empty content descriptor, because the file is in UTF16 format this causes the descriptor to be 0xFF 0xFE 0x00 0x00, the first two bytes are UTF16 byte order marks and the second two bytes are the null terminator. But in this file you have 0xFF 0xFE 0x00 0xFF 0x00 FE 0x00 0x00, so it is a content descriptor containing the two charcters:
0x00 0xFF
0x00 0xFE
which relate to the two charcters you see, of course the values used are the same as the UTF16 Byte Order markers, this is an unlikely coincidence.
So I need you to see if you have a backup of the file, or test with some other files to work out whether Jaikoz has actually caused this or not.
I need to upgrade the forum software.
Sorry my first reply was incorrect, There is a bug with the Lyrics field they are actually always written as UTF16 with ID3v23 whether they need to be or not,this will be fixed next week - however this still doesnt account for the invalid values in the content descriptor.
In case it helps, here’s the sample but with HMM tags, as the file was before running the Jaikoz remote lyrics correction:
I’ve added lyrics to a few albums ripped to mp3 using dbPowerAmp (LAME 3.96 - 3.97) and tagged with HMM as you see in this sample. All have the same two chars in the description.
I hope you don’t find any corruption in this sample file, because that would be bad news for my collection 
Ive just released Jaikoz v2.3.1 which solves the always writing Lyrics as UTF16 problem, let me know how you get on.
Absolutely perfect, Paul! You’re building the best tagger out there – way ahead!