Karaoke Forums

I wasn't aware that being a project manager for Microsoft was a degrading position, and Eben did miss my point again.
Zipping is irrelevant to my point.  Always has been.  If the file was only being copied directly to another point on the disk I would have the same objection.  It's the hardware boys and girls,  THE HARDWARE that concerns me.  Plus the other process which may be occuring to get in the way of proper reproduction.  There are incompetent coders (have you never overwritten a buffer?  Ever?) and virus writers and users who don't know where the on switch is so they just unplug the thing.  It's not a perfect world and karaoke computers get banged around a lot which may make hamburger of your processes lossless or not.  My friends, it is not your math I have the problem with, it's just the unnecessary process, ANY unnecessary process.

Really? Your point is that zipping was irrelavant to your point, always? Let's see.















Seems to me, every reply you made had some kind of reference to zip and why it's an idiotic idea to use it on CD+G files. Now you are saying everything you said had nothing to do with Zip.  :shock: I still don't understand the point you are trying to make.

_________________

Seize the day and SING!!!

wow what did i start here..., yes i zip and will continue too, but thanks for the computer lessons all it was fun
DD

_________________
My heart is steadfast,Oh Lord;
I will sing and make music with all my soul. Psalms 108:1

whats that song bout the wildwood flower?

_________________
"Be who you are and say what you feel... Because those that matter... Don't mind...And those that mind... Don't matter."

Okay, one more time.  CDG is a thin data format and as such is more susceptable to replication error via extra processing such as zipping.  I did not directly attack zipping.  I'm sure it is well thought out and poses no particular danger to data other than in this case it is an extra process.  I mention zipping only because it was the extra bit of processing that was being discussed.

This you have taken as a general poo pooing of zipping.  That was not my intention.
I tried to illistrate my point that computers DO make mistakes by referencing the /v option on the "xcopy" command and you got off on a tangent about two cable hard drives.  I said XCOPY not PARK for goodness sakes.  I haven't seen a stepper motor since about 1983.

I stand by my original statement and it is only my opinion for what it's worth, but if you undertake any unnecessary processing and recopying (such as zipping) with a very fragile file format that in itself leaves no space for error correction not only of the current misinterpretation but of all susequent calculations made which incude that error such as CDG files, you're an idiot.

Now if you want to expound on the virtues of RLL over MFM hard drive encoding from the era of the ST506, some of us would be interested I'm sure but this is a karaoke board after all.

OK, has ANYONE had a error on a mp3/cdg file casued by unzipping?
Yes, I agree it is now, in the days of cheap storage, an unnecessary process.

In my situation, when I was ripping my discs, it made it much easier to rename the tracks to my liking (I don't use MFG numbers).

Again, in 2 years of using my ZIPPED files, I have NEVER had a error from unzipping.  I have had more problems with RF modulators and TVs than unzipping files.

So I will continue to be an IDIOT, thank you very much.

Hmmm, never had an error from unzipping?  How would you know exactly?  An error would cause a blotch.  I'm sure you don't watch every instant of the singer's screen, I sure don't.  But, never mind.  It doesn't matter.  Be happy.

CD+G standard includes quite sophisticated error correction, but only few software products utilize it. For each 24 bytes 6 of them are Reed-Solomon error correction codes. Without them even slightly scratched CD+G would cause problems. If you rip with Plextor drive error correction is done by the drive's hardware. Software like Power CD+G Burner or Siglos Karaoke Player/Recorder do this on the software level not depending on the drive. If you rip with Audiograbber you will get no error correction, but the ECC codes should be in the CDG file, so in theory it is possible to fix them.

I was wondering what to do with those little buggers, the ECC bytes I mean.  Can you point me in the right direction?

I am not aware of any online information. We used CD+G standard documentation from Phillips that had all the information (it involved quite complex math to do the ECC correctly).

Well, let me invite you to give yourself a free plug.  Who is the "We" you speak of and does the ECC acutally unblotch a bad rip?

I guessed it was obvious to find out from my nick

http://www.powerkaraoke.com

Ok, I still disagree with you about both facts, CD+G is a fragile format and zipping CD+G is a bad idea. As Powerkaraoke stated, CD+G uses Reed Solomon ECC to correct many bits that may go bad within the file. If you want to learn more about ECC, check this out. It explains how ECC works. ECC is used in every part of the computer now days. The disc drives use ECC to correct any bad bits with magnetic recording may yield (you'd be surprised how many bits go bad on disc drives and without ECC, they would be useless). ECC is used by many of mission critical system RAM (DDR types specially). ECC is used in many files formats (all files have checksum to check for bad bits, some will actually correct using ECC) including compression files like mp3, MPEG-4, ZIP, CD+G, etc. ECC is used in transmission of files via the Internet, such as TCP ur UDP protocols, as well as IP protocols.

Using these methods guarantee pretty much that the files contents are intact despite bad bits. Can you still lose data? Of course. If you take a back up take and snip out an inch of it, you will lose most of the data. So, similarly, if you lose many continous bits from some kind of disaster you can lose the file.



Alright, I used to work for disc drive companies so I have some insight. The reason for /v option that was used was because the older drives did not have the intelligent to do checksum and ECC within the drive to provide data that is correct. In old days, the drive controlling was done by the computer, thus the command like /park was used to park the heads manually to safe area. Newer drives like IDE (ATA) or SCSI drives, the control is on the drive and the drive does it's own checksum and ECC so the data you are getting from the OS level is the correct data.

Again, your assumption that ECC is not used and the CD+G files are fragile and subject the losing bits when zipped is absolutely false. There are more code in to protect that data than you think and the file format is very safe.

Lastly, MFM and RLL has nothing to do with it, those are method of recording magnetic patterns on to the disc drive. MFM is non "compressed" method of laying down magnetic transition on the the media and RLL is a "compressed" method. These are very low level protocol that is used by the disc drive and you will never see it on modern interfaced drives.

_________________

Seize the day and SING!!!

Eben, my very learned freind.  We are just not communicating.  I mentioned RLL and MFM transistion coding because they are obsolete and irrelavent, as was your mention of the ST506 type drive.
I cannot agree that unnecessary processing of any kind is a good thing, you however like it so, I am willing to live with that.  I hope you will too.
Now, to ECC.  It does no good if is ignored.  I, for one am about to ignore it unless I can figure out by the end of the day how the parity bytes work in the CDG file.  I suspect a lot of people have ignore them in writing their CDG players as they hit the same wall I did.  I would like to get the software completed, tested and on the market by the end of Feb.  If I don't have product I can't sell product. If I don't sell product I don't get paid.  If I don't get paid I can't buy beer.  THIS IS A BAD THING!
Any chance you would like to explain how the ECC works in the instance of CDG command packets?

Well, some progress.  I think I know what the first pair of parity bytes do.  They confirm the instruction as in instruction 6 is always (at leas in the dozen or so files I have examined) followed by 53 and 58.  But about these last four....

This is the most technical thread I ever seen in this forum. 2 developers and 2 other programmers contributing  Wow.

_________________
I can neither confirm nor deny ever having or knowing anything about nothing.... mrscott

Bytes 02 & 03 (indexing from 0) are ECCs for instruction code bytes (00 & 01). And bytes 20-23 are ECCs for entire pack (including instruction code and their ECC). 02 & 03 are Reed-Solomon 2-4, and 20-23 are R-S 20-24.

Bless you!  That's just what I was looking for!

OOOPPPPSSS!  I forgot to thank Eben too.  This will be a great help to everyone who doesn't see blotches on their screen as a result.  Thanks again guys!

What you up to????  DO I hear a new hosting/ripping program in development?