Two Ripping Questions I Couldn't Find Answers To...

[SWLinPHX]

I am happy to see how well kJams works (especially since I haven't used it in a long time and now with my new MB Pro -- it even rips from the MB Pro DVD drive!). I have two primary questions regarding ripping.

Years ago, when I first ripped a couple CDG's on an early version of KJams (kTunes) it ripped them as zipped files, placing them inside the kJams Music folder inside the folder for the disc number: kJams/AH2004/ALH2004-02 - Green Day - Basket Case.zip Now, a long time later when ripping with a new Mac, new OS and much newer version of kJams, despite having the import preference set to "zip files when ripping", it instead rips them all has mp3/cdg pairs (and then later creates the accompanying .xml file as well) all with the same name. Is there an issue with the "zip when ripping" feature or am I doing something wrong? I'd like to be uniform so they're all zipped or not when ripped. I understand not zipping saves CPU usage but my MB Pro is fast enough and it seems a folder with 16 .zip songs consistently is somewhat smaller than one with 16 mp3/cdg pairs, or am I mistaken?

Also, while they rip to the same kJams Music folders as my first two discs from long ago, they instead rip as such: kJams/Green Day/AH2004/ALH2004-02 - Green Day - Basket Case.zip. I think it is an unnecessary extra step to group all by artists in the Finder first before album/disc and song/file name. I use iTunes or kJams to view by artist, but prefer they be grouped by disc, viewing all songs on each disc together in Finder view. It is a hassle to move and re-order them all in the Finder after each rip (although I have managed to do so without kJams losing sight of the file location). Any suggestions?

I have a huge library to rip and due to unforseen circumstances, am just now getting to it. Thanks for any help!



UPDATE: One last ripping issue of note I just discovered. If you rip with kJams Lite version, it will only let you rip the first two songs to start, even when selecting the entire disc. You must then select the remaining songs once the first two are done and it will rip them all in another session. I take it this is some sort of leftover from the 2-song burn restriction in Lite???

[dave]

1: bug
2: by design, but not necessarily a good design. you can export the entire library to what ever organization you want, then trash your library, then import your "personalized" folder. or, you can decide not to care how kjams manages the files in the finder.
3: bug

[dave]

3: are you sure you've got a Licensed version of Lite? If you bought Pro then you don't get Lite automatically, so it'll have the 2-songs restriction. But then, you could not rip the rest at all either. So i'm confused.

[SWLinPHX]

Oh no, I had paid the initial fee to get Lite but then never upgraded because I thought I wouldn't have regular singers doing private parties where everyone is different each time, but now I will upgrade with the new Web Server feature (need to read up on that!). But it had been so long since I took it for a spin I wanted to get reacquainted first. So is this 2-song initial rip-limit a bug you already knew about? Is it supposed to only be 2-limit burn with Lite?

Also, are you saying it is already a known issue that they files don't zip even when you tell them too when ripping? If so, why did they rip a couple years ago as zips automatically?

Are you saying you think it's not good to have them grouped by disc in the Finder? Again, this is how it was done in the past on kJams/kTunes and with the current Artist system you have an extra folder hierarchy level to muddle thru and you can't see them all as one unit (all the songs on the disc) in Finder view. How were both these things working as specified before, long ago? Did you deliberately change it, or...?

Oh, and to ask you again: Even if zip is slightly slower to open on older computers, do they take up a little less space than the exact same song as a mp3/cdg pair or is that a fallacy?

[dave]

no, it's not a known issue, or rather, it hasn't been until you brought it up. Actually i can not reproduce the problem at all. With a registered Lite, i select the first five tracks, drag them to the Library icon, and they rip one at a time, all of them, no problems.

And no, it's not a known issue that the Audio+G files are left littering the song folder after they're zipped. Not until you brought it up (and one other person, on the same day), and i still can't reproduce that either. in my mind the definition of "known issue" is that everyone can experience it and i have reproduced it as well, but i haven't fixed it yet.

re: grouping in the finder: i'm saying you should stop caring about how things are grouped within the "kJams Music" folder anyway. that folder is supposed to be opaque to you, it's the database that kJams manages, pretend you can't see inside. if you want to extract stuff from there, use the export command, and you can export to any folder heirarchy style you enjoy. they're all good, none are worse than or better than any other. it's just that kJams *expects* the style you see inside it's own folders.

use zip files, they save space and take practically zero time to unzip, even on older computers.

[SWLinPHX]

...use zip files, they save space and take practically zero time to unzip, even on older computers.

Well that's just it... I can't use zip files as I explained when ripping, because the "zip files when ripping" option isn't working as I explained above. I'm confused about what you mean by the Audio+G files littering the song folder. They don't when I use zipped files (just the zip file plus .xml remain). However, again, I was saying that I can't zip when ripping. I think you confused me with the other guy you mentioned, maybe.

[dave]

Well, something strange is going on with your system, i'll have to have a look-see next tuesday, we'll get it figured out!

[SWLinPHX]

Thanks Dave. Was just by chance a friend I hadn't seen was finally available and I forgot on Thursday. But this time I wrote it down; got you in for 9PM PDT/MST Tuesday.

[dave]