[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: GiacomoGo  XML
Profile for GiacomoGo -> Messages posted by GiacomoGo [42] Go to Page: 1, 2 Next 
Author Message
"Revert to Saved" file menu option is not working as I expect.

I expect Jaikoz to re-read file tags from disc, but it does not. In other words, for me "Revert to Saved" really should be "Re-read from Disc", but it is not. Perhaps I don't understand what "Saved" refers to.

Here's from the online manual:
http://www.jthink.net/jaikoz/jsp/help/windows/ch05s06.html#RevertToSaved

"Saved" changes are in my mind basically what I have on disc in the track tags.

So for example after loading a folder from disc, update tracks in an external (non-Jaikoz) app -- dBpoweramp, Helium Music Manager, etc. Then back in Jaikoz, I choose "Revert to Saved". I expect to see the most recent track details that I updated from the other app.

I don't.

I've also tried to empty the jaikoz cache, then "Revert to Saved", thinking that this would force a re-read from disc. It does not.

So the only way to get what I expect is to close all files, and then re-load the folder.

Is this as intended?

paultaylor wrote:
No Im saying I need to fix Jaikoz so that is uses the Roaming folder but I have not. 


Not to nag, Paul ...
I've just installed jaikoz 8.0.0, after uninstalling my prior version completely (including removing folders from my filesystem).

After installing Jk8, I get these new folders:

C:\Users\%USERNAME%\Jaikoz with
license and settings files
\jaikozdb\ subfolder and
\tagBrowserIndex\ subfolder and
\logs\ subfolder

And nothing in C:\Users\%USERNAME%\AppData\Roaming\

I can use the General -> Database setting to move jaikozdb to:
C:\Users\%USERNAME%\Music\Jaikoz\jaikozdb\

But I still cannot move C:\Users\%USERNAME%\Jaikoz into my AppData\Roaming folder.

Is this one on your radar for Win7?

Thanks!

paultaylor wrote:
No there isnt, and really all these files should be going into C:\Users\username\AppData\Roaming\ 


That would also be OK for me, as long as they go by default into one folder, whether to Roaming\Jaikoz or to the User Database Folder in the preferences.

Could you please confirm, Paul, whether this is coded and working accordingly? With a fresh install of Jaikoz 64-bit on a fresh (fully updated) install of Win 7 64-bit, this is not what I get.

Thanks!
In the Jaikoz preferences, I can change the Database Folder. I've chosen:

C:\Users\Username\Music\Jaikoz

However, Jaikoz nonethless creates another, unwanted folder one level higher for other files like license, layout and settings:

C:\Users\Username\Jaikoz

I can't find any way to tell Jaikoz to use just Music\Jaikoz for all user files, and never the higher-level folder.

Is there a way?

Porthos wrote:
I too use Jaikoz mostly for getting lyrics & making sure tag data is correct.. Jaikoz is my one stop solution.

I hope you can find a solution.
 

Just to reinforce that Jaikoz has been the single best lyrics retrieval tool. It's the only one I use. So best wishes, and hoping for a solid solution (quick, alone, is less interesting).

Many thanks.
MS Technet may help with details:
http://technet.microsoft.com/en-us/library/cc753194(WS.10).aspx

I use "mklink /d" directory symbolic links rather than the "mklink /j" Directory Junctions, but by default MS loads Win 7 user profiles full of "junctions" as a kludge for moving a bunch of standards folders around (and shortening names) without breaking XP software.
... I suppose it's not just to open folders, but browsing folders in general when trying to access files/folders on a Win 7 system.

These are Win 7 symbolic directory links, not junctions or other types of shortcuts.

Jaikoz just does nothing when I double-click such links when browsing for files. Ie, it doesn't recognize this as a directory, so doesn't add it to the "File name:" path.

If I manually type the folder/path into the "File name:" field, Jaikoz does seem to handle it properly ... so perhaps just a browsing problem.

I didn't test whether Jaikoz can properly handle a subfolder SDL when loading files, but that should work as well.

paultaylor wrote:
Havent been able to reproduce yet, but I have had problems like this in the past so possible regression 


Seems resolved for me with 3.4.3 or 3.4.4.
Thanks,
Does not re-read tags ... maybe that's intended? It only undoes changes made but not committed via Jaikoz?!

After loading an album, I modified the tags via an external app (HMM to apply a few customized HMM tags).

Then back to Jaikoz and tried to "RTS", which did not read the new HMM custom tag elements.

However, if I close all files and re-open the folder, Jaikoz does read all the tags properly.

I would expect "RTS" to function the same as close/open.

paultaylor wrote:
Okay the list of problem characters isnt clear, any more just let me know. 

Just to confirm that 3.3.1 solves these issues for me. Thanks again, Paul, for remarkably great software!
Great to see that Correct Lyrics now handles apostrophes (single-quotes). Just to be a trouble-maker I had to try something with double-quotes. Seems that these still cause a problem:



But the complementary enhancement to provide the lyricsfly link helps with this quite a bit.

Great stuff!

paultaylor wrote:
Thanks, good find 

You're quite welcome, Paul. You've got the best software out there.

When you announce a fix, could you please comment on combined titles? Eg, like "Eruption/You Really Got Me", above, I often rip tracks together when one is really an instr. intro to the other. For me, at least, if a title does not match directly, then the "/" indicates multiple titles. The most extreme examples I have in my own collection are the b-side medleys from Abbey road:

Mean Mr. Mustard/Polythene Pam/She Came In Through The Bathroom Window
Golden Slumbers/Carry That Weight/The End/Her Majesty

It would be great if Jaikoz could support lyrics for such tracks ... although I can imagine that's a tough request, or unwarranted effort for the exceptional case (I have 40 tracks like this in my collection of 4300 ... <1%). It likely makes most sense for me to simply go to a lyrics web site directly and manually copy/paste a few lyrics.

Thanks, again, for great software!!
"Correct Lyrics" works great as long as the track title has no non-alpha/num chars. For example:



or:





Would be nice to sort this out to eliminate sensitivity to such "punctuation".
Otherwise great stuff!!

paultaylor wrote:
Okay, this is an occasional problem with a lock being held on Jaikoz database even though database is not running, you need to go into your users Jaikoz folder and delete the jaikozdb folder , then should be able to start Jaikoz okay 

Thanks, that worked. But I still get spontaneous exits (fatal errors) within a few minutes of starting Jaikoz. I'll send logs by email.

paultaylor wrote:
If Jaikoz is failing to start on your OSX system please apply the following fix

http://www.jthink.net/jaikoz/jsp/fixes/start.jsp

if you are not having an issue there is no need to apply this fix 

Doesn't help me on WinXP SP3:
http://img200.imageshack.us/img200/965/screenshot002o.png

I've tried clean install (uninstall old versions first) and reboot.
edit to be clear: I'm definitely only running one instance.
Perhaps it's just my old system, so I'll ask if anyone else is having the same display problems with the Edit tab. When I scroll, the display does not update in real time, but only after I pass the mouse over the rows.

See attached screen shots. Notice in the first how the column headers are out of sych with the Edit rows. In the second, I've moved the mouse across the first rows.

It's definitely an old system, but this was not a problem with an earlier version of Jaikoz (pre-3.0?) or Java (1.6.07?). I've just upgraded memory from 0.5Gb to 2Gb, without improvement on this particular behavior.

Is anyone else seeing this annoying display problem?




According to dBpowerAmp, which I use to rip my CDs:
http://www.dbpoweramp.com/codec-central-m4a.htm
The iTunes Audio Book format is identical to .m4a -- but iTunes knows what to do with the modified extension.

It would be great if Jaikoz could support the .m4b just as it does .m4a!
Thanks, Paul, for resolving via email.

YES! you were right -- ACTivating the "Save -> iTunes cmopatability -> Do not unsynchronise ID3 tags" fixes the image in both HMM and dBpowerAmp.

Apparently like iTunes neither of these ID3 readers can handle unsynchronised tags.

That then also solved the HMM lyrics tag as you expected. I never would have guessed, so thanks again for investigating.

paultaylor wrote:
You can email me at support at jthink dot net 

Thanks for having a look, Paul. I submitted a few files by email. Let me know what you detect.
Don't know when this started again, but am now having the same problem wit Lyrics previously resolved here:

http://www.jthink.net/jaikozforum/posts/list/360.page

This also seems related to the older Lyrics problem reported here:

http://www.jthink.net/jaikozforum/posts/list/342.page

Seems Jaikoz is always saving lyrics in UTF-16, again.

Also, now cover art embedded in tags with Jaikoz can't be read by other reliable tag readers (see screen shots of dBpoweramp chocking on a Jaikoz tag, but reading without issue Helium Music Manager tag -- same .jpg used for both tags, both apps).

paultaylor wrote:
Did these use to exist, does the problem persist if you reload the file - if it does it would help if I could look at the physical file, if it doesnt then this is a glitch in the Gui. 

I've just installed 2.4.0, and again opened the same file as the screen shot above. All looks fine. Jaikoz properly displays missing/blank tags -- the "missings" which previously showed as "blank" were always missing since ripping with dBpoweramp. Whatever the issue was prior to 2.4, it's no longer an issue for me.

I tried loading a few random Artist directories, each with scores of tracks, and still no problem!
Please see attached screen shot.

There still seems to be some randomness in field coloring, between green (missing) tag elements and white (blank) elements. The screen shot below is for a single mp3 file for which none of the pictured tag elements exist (according to other id3 tag readers -- dbPowerAmp, Helium Music Manager).

Am I reading this wrong, or is this just something to live with?

paultaylor wrote:
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!

paultaylor wrote:
... - 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:
<link>

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

paultaylor wrote:
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, ... 


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
net.jforum.JForumExecutionContext.enableRollback(JForumExecutionContext.java:272)
net.jforum.JForum.service(JForum.java:209)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
net.jforum.util.legacy.clickstream.ClickstreamFilter.doFilter(ClickstreamFilter.java:59)

Enricus W. Funk wrote:
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.

4ms wrote:
How do you use these programs together?
Do you use Jaikoz to get metadata by acoustic id and then use dBpa to organize with conditional names? 

4ms,
Myself, I'm more interested in Jaikoz for the complete access to tags, rather than metadata retrieval. I simply rip with dBpoweramp (creating my correct folder structure) & then clean up or complete tag info using Jaikoz or Helium Music Manager.

For me these 3 apps together allow total organization & enjoyment of my music collection. I store, play, sync my player completely from HMM. Nothing but these 3 perfect (but constantly improving) apps is necessary: dBpa (ripping), Jaikoz (tagging), HMM (manage, play, sync).

4ms wrote:
The bigger challenge may not be 'classical', per se, but more generally the compilations - and how to name them consistently. 

For me, dBpoweramp and Jaikoz set the gold standard for ripping/tagging. I think I am not alone. So perhaps dBpa offers a basic model for at least conditionally naming compilations -- perhaps one that can be extended more generally to other tags such as genre:

dBpoweramp conditional paths/names

newname wrote:
What is the difference between Joint Stereo and Stereo? Which one is better? I have identical songs except for that part. Which one should I keep/delete? 

I doubt anyone will say A or B. It depends on the original recording and your personal priorities. But this should help you decide:
Wikipedia entry
see also JS details
I've checked the offline help file & can't find specifics about writing out "Not Supported" and "Unknown" frames. It seems Jaikoz handles them differently.

Mostly, I'm wondering:
1) Are these columns dependent on tag version? Eg, is TDRL "Unknown" in an id3v2.3 tag, but supported for an id3v2.4 tag?
2) Are "Not Supported" and "Unknown" frames both written when saving the tag? Does this depend on tag version?


Jaikoz Help says the app should recognize all official ID3 frames. TDRL *is* a valid frame, although only in an id3v2.4 tag ... not an v2.3 tag.

I ask because it seems that Jaikoz *always* writes out "Not Supported" tags, but *doesn't* write out "Unknown" frames.

I've also noticed this problem:
If I open a track that has an id3v2.3 tag which is augmented with some v2.4 frames like "TDRL" or sort order frames like "TSOA" & "TSOT", then Jaikoz considers these v2.4 frames "Unknown" and does not write them out if I change some other frame. (Helium Music Manager writes such mixed tags as "compatible" v2.4 tags ... compatible with v2.3.)

However, if I try to update the tag version to v2.4 using Jaikoz, and then save, Jaikoz still seems to throw out these "Unknown" v2.4 frames, rather than trying to fit them into the updated v2.4 tag.

If this is all more or less accurate, then I'd suggest either
1) always display tag info based on the tag Version (including a proposed change to Version). Then, if a user changes tag Version, Jaikoz would re-scan the track based on this new tag version, and then try to apply any other changes the user made but didn't already save; or
2) always display tag info based on Jaikoz's best interpretation of all tags. In this case, Jaikoz would recognize TDRL, even in a v2.3 tag.

3) Jaikoz should also always write out all "Not Supported" and "Unknown" tag frames. I appreciate Jaikoz's adherence to specifications, but given the lack of conformity out there, this would help avoid loss of data from other applications.


My preference would be 1 + 3. Option 2 seems to cause too many problems.
 
Profile for GiacomoGo -> Messages posted by GiacomoGo [42] Go to Page: 1, 2 Next 
Go to:   
Powered by JForum 2.1.6 © JForum Team