building kma database

[bendrew]

I have no problem with space so I'm preserving my database as kma. And this is what I do now: First, I use songverter to convert zip to bin and use hoster to convert them to kma. I have no problem doing this but right now it takes time to do it. Would it be better if I use songverter to convert them to kma (it's faster)right away and do build the database afterwards. Which one is better to apply. what better options do we have. Your opinion is appreciated. Thanks.

[ddouglass]

The way you are doing it is the way it should be done. The conversion to KMA in Songverter does not assign a BookID so Rebuild would not work. You would have to use Add and they would not be put in any kind of order.
Not a good idea. Stick with what you are doing.

[dallaspaul]

I have a similar issue with space. I notice that BookID is a THREE character field, thus I assume limited to 001 to 999 inclusive. When I import disks via hoster, whether by single or batch, it changes BookID as the source disks change, which is logical, as the track number of each disk begin with 1 (one). The hoster program instruction manual states that track numbers are two digits, meaning 01 to 99 inclusive.

My question: Is there a method/manner/program in which the KMA files can be renumbered, so that the remaining tracks (eg.: on a 8+8 disk, where only 8 performance tracks are imported, meaning upwards of 92 tracks are wasted) can be utilized per each BookID?

OR
Is there a method/manner/program that can utilize more that one database at a time while running HOSTER?
While most of my original disks contain 14 to 30 tracks, with 15 being most common, I realized that the result would be that I could have as few as 8,000 songs to a maximum (using the common 15 tracks per disk) of 15,000 songs. Not good. I still have 600 disks to import....

[ddouglass]

Originally Posted by dallaspaul

I have a similar issue with space. I notice that BookID is a THREE character field, thus I assume limited to 001 to 999 inclusive. When I import disks via hoster, whether by single or batch, it changes BookID as the source disks change, which is logical, as the track number of each disk begin with 1 (one). The hoster program instruction manual states that track numbers are two digits, meaning 01 to 99 inclusive.

First The bookID is not limited to 3 digits. With Version 4.xx it is actually up to 5 digits or 1 through 99999. The leading zeros are not shown. The track numbers can actually go up to 4 digits if needed but defaults to 2 unless it goes over 99.

Originally Posted by dallaspaul

My question: Is there a method/manner/program in which the KMA files can be renumbered, so that the remaining tracks (eg.: on a 8+8 disk, where only 8 performance tracks are imported, meaning upwards of 92 tracks are wasted) can be utilized per each BookID?

Considering my above correction then I don't think you have to worry about running out of BookIDs for all your CDs now or future. To answer your question no there is no way to add more as each BookID is tied to one DiskID.

Originally Posted by dallaspaul

Is there a method/manner/program that can utilize more that one database at a time while running HOSTER?

While most of my original disks contain 14 to 30 tracks, with 15 being most common, I realized that the result would be that I could have as few as 8,000 songs to a maximum (using the common 15 tracks per disk) of 15,000 songs. Not good. I still have 600 disks to import....

If the limit was that low, then a lot of us would be in deep trouble. I have over 19,500 selections in my database. This is from just over 800 CDs and I still have plenty of room to add more. I will be long retired and gone from this earth before I could fill Hoster up with 99,999 disks.

So you see stop worrying.

[dallaspaul]

Many thanks for the prompt response. A related question: I have songs originally imported with microstudio - for burning to CDs. Can these be added to my database?

[ddouglass]

Yes they can. They are in BIN format which will import and create KMA files.