No! Don't renumber my BookIDs!

[admin]

Originally Posted by admin

I'm looking for feedback on our renumbering the BookID.

Hummm.... some of you failed to read the above part of my post! Let's leave out the "knee-jerk" reactions and think positive. OK?

Digital Party... THANK YOU for your suggestion. That is what I am looking for; working together with us. If we simply start numbering the "new BookID" from the last one in your Songs Database, that looks like it IS the answer! I have just spent 5 hours coming to that conclusion.

However, we don't have a buy-off from MTU Programmers yet. It does look very promising though.

Some MP3+G and ZIP files already don't have Brand-DiscID-Track# identification. Currently, it is impossible to import these into Hoster 3.108. Hoster 3.109+ MUST allow batch importing INDIVIDUAL Files as KMA files indexed in the Songs Database.

While you have been posting, I have been thinking... because I was ALREADY AWARE reprinting Song Books is expensive.

When we cut over to "Song based BookID", we would do the following:

1. Remove the Import Screen BookID Root field and Next button. The new "Song based BookID" will be automatically assigned to prevent duplicates. Any older duplicate BookIDs that found will be renumbered using the next higher number. The BookID will PROBABLY no longer follow the current BookID ROOT+Track#.
   
   Here is a problem. The Import screen Status field shows IMPORTED when a file has already been imported. This CURRENTLY requires the DiscID, which is uniquely tied to the BookID ROOT. I doubt if we can continue to do this check and verify. There is a LOT of code and error checking behind this function. I'd hate to see it disappear.
   
   
2. Add a "Merge Songs into Database" command. Whenever you add existing KMA files (ex: imported on your backup system) into Folders identified in the Build Songs Database command, the Build Songs Database command will add them to the Database IF... they do not have the same BookID as one already there (determined by which was processed first). With Auto-Renumbering, your Song Book would be worthless following a rebuild of the Database. A Merge command would start with the EXISTING SONGS DATABASE (and thus Song Books), and add any new files into it, renumbering ONLY the NEW files that are currently NOT in your Song Book. The Unprinted tracks for next Song Book parameter will be reset to zero when the Merge command runs, and its count updated with each new merged song. The Print New Release Pages option in the Prepare Song Book dialog will then work as it does now. In case you can't see it, the "elegance" is starting to happen here!!!
   
   
3. Allow Edit Songs dialog Select Single tab to edit all fields, except BookID. Editing the BookID is not required with automatic renumbering. If scant song info is present when imported, you will WANT to edit these fields.

If song filenames only have Title and possibly Artist, duplicates will happen. When MP3G and ZIP filenames contain the DiscID and Track# fields within the filenames, Hoster 3.108 searches the Import and Song Databases. If the DiscID is found, it automatically fills in the Title and Artist fields before importing. We will add a new means into Hoster 3.109 (not in 3.108) to batch import MP3G and ZIP files. You can have FAST IMPORT, or CAREFUL IMPORT. The latter takes time and attention. We will try to create the new means to be unattended if desired. There is no other way to get 20,000 MP3G songs into KMA files and indexed in the Songs Database. At 1 second/song (which is the right ballpark for converting MP3 based files), 20,000 will take 5.55 hours. That's with the FAST IMPORT with unattended operation. If you are involved, it will take MUCH longer, but the songs will then be CAREFULLY IMPORTED. Our goal will be to provide the "tool" to allow both.

Now it's your turn... please evaluate and post your comments on these proposed changes.

[Digital Party]

MTU,

I am in your hands.......I know that you have the interest of us users in mind, thanks for that. You do what you do best and let me know what I have to do. I know that redoing my books can cost money.....let's look at this......

If you are trying to do the best at your Karaoke shows, you will have to upgrade your books soon anyway......I get new music every couple of months. Some people get new music every month, some every 6 months,....some never do (OH NO!!! DID I JUST SAY THAT? ) TRY CHARGING MORE FOR YOUR SHOWS....LET'S RAISE THE BAR ON SHOW PRICES ACROSS THE NATION (OH NO!!! HE SAID THAT TOO ) OK...that's enough on that.......

I will be downloading the new hoster, and playing around with it a little first before I upgrade for my shows. I want to make sure that everything is OK before I go out in public. That's just me.

Remember,...If you are doing your shows as a business,.......The cost of new books is tax deductable, in the long run. Pay now, get it back at the end of the year. My CPA is always telling me to "Spend More Money". I tell him I don't have anymore to spend. In the end, we will all have a better product. This is the only KJ software that has been THIS STABLE for me.

MTU.....TELL ME WHAT YOU NEED ME TO DO!!!! I'M JUST GLAD TO BE HERE

[Party of one]

If I jumped the gun on MTU vision of changing the numbering system in the next update then I'm sorry. The main fuction of a good show is your books. No matter how good of a system you have if they can't find the songs you are dead meat. Just the thought of changing my books after all the hard work I put in just makes me shudder. Like I said before I've been on MTU side telling everyone that hoster is the way to go. I was even able to get someone to buy hoster. Glad to see that we have time to makes our desions on what we would like to do. I'm so used to hoster I would hate to have to do a show without. That would be a disaster. Thanks for this forum where we can give our views like and dislikes.

[djbrian]

First, the most difficult thing in the new numbering system would be for the returning singers who I keep their slips from week to week. Thats not really that bad, it's just a matter of changing the song numbers on their slips. Everthing else sounds like it's automatic. All you have to do is print the books. I know that the paper and ink isn't free, neither is your time, but I have 8 books that I have to re-do, all in page protector sleeves. I would welcome the change of the automation so that I don't have to use a third party songbook program (Music Book Deluxe) anylonger. The only advantage to their program is the availability of updates to the database monthly via automatic download when you are online with the software running. That would be MY most desired feature to include in future versions!!! Otherwise, the zip and mp3 coversion and renumbering is necessary! I just bought Hoster, after using Sax & Dotties for the last two years, I have to re-do everything anyway. I have ALL of my music imported into ZIP files fron audiograbber. I need the conversion ability very soon!! Otherwise it is a very long process that I must go through to re-import all my songs AGAIN in the KMA format.

Brian

[Party of one]

Just a thought about renumbering. I don't use hoster books because when I first got hoster their database was first name first. Now they change the database to last name first. So half of my database is first name and half last name first. So I use exel so I would have to start all over again. That's why I would have a lot of work ahead of me. Actual I use KJpro then export to exel. Either way I'm in for alot of work. That's where the rub is on me. I guess I'm in this alone so I will have to deal with this problem. If I had not had my database split I think I wouldn't mind so much. The thought of loading all the disc to the hard drive to match with one last name first would take too much time. (I've already done it twice that's another story) Now if I could do it without loading every disc. I would use the hoster database and the numbering wouldn't be as bad. Just my thoughts.

[Digital Party]

The regulars that keep there slips from week to week will forgive you . If you have a good show. I don't keep slips for anyone. If they want to sing, fill out a new slip. Ain't got time for that.

Yea....sometimes it's a lot of work...I used to use KJPro. Don't know why you would not want to use the Hoster Book function. After you do it once, it is just so easy. KEEP SMILING AND SING

[Party of one]

Yea....sometimes it's a lot of work...I used to use KJPro. Don't know why you would not want to use the Hoster Book function. After you do it once, it is just so easy. KEEP SMILING AND SING

Digital Party
I would love to use hoster book fuction if my songs weren't split between first name first last name first blunder. (Sounds like who's on first) It's a mess, hard to explain.

[DJYale]

Some MP3+G and ZIP files already don't have Brand-DiscID-Track# identification. Currently, it is impossible to import these into Hoster 3.108. Hoster 3.109+ MUST allow batch importing INDIVIDUAL Files as KMA files indexed in the Songs Database.

.................

Here is a problem. The Import screen Status field shows IMPORTED when a file has already been imported. This CURRENTLY requires the DiscID, which is uniquely tied to the BookID ROOT. I doubt if we can continue to do this check and verify. There is a LOT of code and error checking behind this function. I'd hate to see it disappear.

For MP3+G and ZIP files without a diskID, What about using an entry such as cst????-??. (I used cst = to custom for the example, the first 7 characters being the DiskID, the second two after the - being the Track)

Here's the logic in this:

1. Say I have 12 songs by elvis that are in MP3+G format I want to import. Using the second method I could assign a DiskID of cst1001-01 for the first then increment the number after the - for each one, putting all the songs by Elvis under one DiskID (the number after the - being used as a TrackID)
   
   
2. In a batch import of non-related songs contrary to the above, You could either have the user enter a starting DiskID (CST1001 for example) and a Max Track ID (say 1 through 20), or have an Auto-Increment DiskID check box that would automatically find the first open CST???? Disk ID available and start from there. The import could then start with CST0001-01 for the first imported song, then increment the track ID until it reaches the Max value. Then move on to the next available DiskID (CST1002). I'd recommend a check box for this along the lines of "Automatically increment DiskID". This way, those who want to assign their own DiskID's for each "set" can, and those who just want to import them can tell it to Auto increment and let it go.

This would assign all imported songs with a unique DiskID-TrackID combination. And unless I missed something (highly possible) would keep the existing BookID system intact. Granted there is nothing to prevent the user from importing the same song multiple times under multiple DiskID-TrackID combinations except being cautious in the even the song does not have the combination in the file name.


Also, say down the line I get 3 more elvis songs I would like to import, I could go back to the original DiskID (CST1001 in the example) and add them to the end using the next free TrackID entries. In the example that would be CST1001-13, etc.


This would give users some flexibility in maintaining their lists when it comes to MP3+G's that have no associated DiskID-TrackID, while maintaining the current structure.