Automatic CDG repair (more grid stuff)

Is kJams missing a feature you need? Post it here! Note: if iTunes has it but kJams doesn't, it's a good bet kJams will have it, but that I just haven't gotten around to it yet. But go ahead and request it anyway!
Post Reply
DeusExMachina
Posts: 1293
Joined: Sun Apr 20, 2008 9:57 am
Location: Pittsburgh, PA
Contact:

Automatic CDG repair (more grid stuff)

Post by DeusExMachina »

Mentioned this once before, but bringing it up in the context of the grid
Didn't list this feature in the grid because I had not tested it in all apps, but several claim to have better CDG playback even from damaged disks.
In working with Producer to fix glitchy tracks, and seeing how many, if not most, errors are quite stereotypical, I have several "algorithms" in my head that one could run that would clean up 90% of the damage seen in these things.
When a track was run through the Cleaner:
1) Any channel for a font that was not 0 would be set to 0. (Very few, if any, standard CDGs EVER use the other channels, and frequently lyrics get damaged on screen because a font was set to some other channel, leaving a gap on the screen.)
2) Background colour (0) always stays the same throughout track.
3) Using a preset value for number of colors (usually two) any change to color 0 or color 1 after a certain time code would be disallowed. Any change to color zero would be reverted.
On duets, number of colors jumps to four.
Regardless, even where the author went hog wild and let a unicorn puke rainbows all over the screen, all color changes that only took place on one font would be reverted to the previous (or next) colour value.
Colour values that spanned a threshold number of fonts would be preserved.
4) When a font's row or column value was such that the font would be off the screen or,
if the font's row/column value changed precipitously for a single font, it would be changed based upon a simple algorithm. Since all major CDG producers use text that is two fonts tall, the text is usually drawn algorithmically, row/column, row++/column, row/column++, etc.
This changes slightly when it is either a duet or does line by line lyric sweeping, BUT you can accommodate this by checking the colour of the font that "jumps". If it jumps AND is the same colour as the preceding font, it is almost certainly a glitch. Since this defaults to the same algorithmic check with paged lyrics and non-duets, this serves both.
The algorithm would scan for the pattern of changing font row/column, and fix clear glitches (fonts that jumped from the pattern as seen both before and after it) by setting the font position to values predicted by the pattern.
E.g., lyrics that draw a screen often do so by starting at a given row, column, and either scanning across (row, row++, column++, row row++, colum++,… new row… etc.) or top to bottom column, row, row++… etc., new column, new row… .)

These could be ranked by order of aggressiveness. A slider would let the user determine how much fixing to do.
This could also be used live, turned on via a preference, with an alert that told the user there was a glitch detected, and allow the user to save the fixes after playback, or mark the track in the DB (or move it to a playlist similar to damaged ZIPs) to be reviewed later.


This could be implemented in phases, since #1 is easy (just set every font's channel to 0) as is #2 (set color 0 to initial color 0). #3 is progressively more difficult (needing heuristics to determine number of colours and if an edit is required, which colour to set it to). #4 is the most complicated, of course, but one thing that would be easy it just to notice when a font jumped more than 1 column without changing rows. This would almost ALWAYS be a glitch. The font could then be moved to a spot matching the known sequence.


Alternatively, the time codes that kJams saw these glitches could be noted, tagged in the XML, and used to jump to the appropriate time codes when the user reviewed the glitches, to fix them by hand.

This covers about 90% of all the glitches I have seen. The last 10% are spurious pixels in a given font. These could be tracked based upon the colour change to the sweep colour (marking it a sweep text) and then making sure there is a one to one pixel match between the font that drew the pixel in the first place, and the sweep text font.

Not sure if any of this is what the companies that claim to fix glitchy CDGs do, but this would certainly qualify for a grid check!
Last edited by DeusExMachina on Thu Oct 19, 2017 10:01 pm, edited 1 time in total.

dave
Site Admin
Posts: 6684
Joined: Sun Sep 18, 2005 8:02 am
Location: Seattle
Contact:

Re: Automatic CDG repair (more grid stuff)

Post by dave »

an interesting idea, but i honestly don't feel the cost / benefit ratio is worth it. the future of karaoke is video anyway.

Post Reply