On Sat, Feb 14, 2009 at 8:34 PM, Tim <tim-proje...@sentinelchicken.org>wrote:
>
> Perhaps this is a known problem, but I thought I would bring it up.
>
> The .cdg tracks I just ripped look normal at the beginning of a song,
> but the longer you play them, the more random mis-colored artifacts
> start to show up on the screen. It's like random chunks of text don't
> get erased properly and start to muck up the screen over time. It
> gets very distracting later in a songs. I can take a screen shot if you
> aren't sure what I'm talking about.
>
> The funny thing is, I've seen these same problems on two separate
> commercial karaoke players, one at a bar and another on a home system.
> At the karaoke bar, the artifacts continued to acummulate over time on
> several songs and eventually the system crashed and they had to restart
> it. Fun stuff.
>
> Thoughts?
I can chime in on this one, I think :)
It's definitely a "known problem," but one known about CD+G in general, not
in the player.
CD+G isn't a video format -- each frame is the result of taking the previous
frame and executing an instruction to change some portion of the screen.
It's an old format, intentionally designed for media that is guaranteed to
deteriorate with use and eventually stop working entirely. It has no concept
of "lyrics" -- it's not just a pile of words and timing information. It's a
stream of very primitive commands executed at regular intervals that draw
pixels on the screen.
In fact, CD+G consists of only a few instructions, like "set the color
palette to be this set of colors," or "clear the screen by setting every
pixel to this color," or "draw this 12x6 pixel image on this part of the
screen." No joke, btw -- the biggest block of pixels you can draw at once is
tiny. There's also some functions for scrolling, and the system is fast
enough to permit rudimentary "animation" by cycling the colors in the
on-screen palette.
You get 75 of these actions per second to work with, and that's it. It may
sound like plenty (and usually it's sufficient, though you can tell in
certain discs where either they just couldn't fit everything on screen quite
in time, or they didn't try very hard), but you've got two limiting factors:
* It usually takes more than one "draw this block of pixels to the screen at
this position" command to get a single letter (or a pair of letters if
you're lucky) onto the screen because the blocks are so small.
* There's no guarantee that any command has executed, and no way to tell if
a previous command has executed.
CD+G intentionally doesn't fail just because a command gets missed. Because
the graphic data rides along with the music, you can't really go back and
re-read a sector again because that bit of music has already headed out to
the speakers. If you look at the spec (linked below), you'll notice that
while there's parity bits to go along with the "P" and "Q" subchannels where
audio CD timing and TOC data lives, there's no parity (and hence no error
checking) on the rest of the subchannels, R through W, and those channels
are where CD+G lives.
Full details on the CD+G spec are available at
http://www.jbum.com/cdg_revealed.html if you're really curious about how it
all works behind the scenes.
The problem you describe arises because players (even the commercial
standalone ones) sometimes miss commands. This can happen because the disc
is smudged or scratched, or because the player gets bumped, etc. Even if a
command executes, the data coming with it can get messed up (an extra pixel
turns on or off when it shouldn't).
On tracks where every frame counts (think of a song like Weird Al Yankovic's
"White and Nerdy" -- an insanely fast-paced parody of a rap song), and
you're struggling to even get all the words on screen at all, much less in
time to be read before it's time to sing them, you may not be able to afford
even a single command (out of the 75 per second you get) to erase tthe whole
screen and start drawing new text. Or perhaps you only have room for one,
and it gets missed because the disc is smudged. Now instead of drawing on a
blank slate like you're expecting, you're just scribbling new graphics on
top of old (non-erased) ones. This is also what causes random pixels to stay
lit up -- they weren't intended to be drawn in the first place (they were
caused by a disc read error), so no command ever follows to erase the errant
pixels.
Every karaoke label does things differently -- Sound Choice tends to use
lots of screen clears, while Chartbuster has a tendency to just erase lyrics
a line at a time once they've been sung and re-use the cleared space for new
lyrics. Because of that tendency, I've seen this "garbage display" problem
happen more with Chartbuster discs than any other label. It gets downright
awful when a read error occurs and turns a "draw a tile" command into a
"change the palette!" command and all the colors on-screen get jibbered. If
the tile data happens to represent an unfortunate combination of colors, you
end up with horrible things like "neon pink background with bright green
letters" or worse, "green letters on a green background." If they never
reset the color palette during the song (either they forget to, or they
don't have time to do so), the whole thing's shot -- from the glitch onward,
you have unusable graphics.
If you set a commercial player to play an entire disc, it's plausible that
(on buggy players, anyway) the unit won't ever clear the screen after it's
started playing, even between songs. The old JVC players (and the "RSQ"
models based on the JVC builds) did clear the screen between tracks; newer
ones, depending on who made them, have trouble with this.
When it happens on a track you've ripped, it's invariably because the disc
wasn't read completely accurately. If you can do so, try to read the disc at
a lower speed (I have never figured out how to convince cdrdao to actually
do this for me -- it always runs at full speed no matter what I try). Oddly,
I've noticed that if I rip a track and it looks funky on my desktop (the
same machine that ripped it), but then use cdg2bin.py to master a new CDG
disc containing that track, burn it, and play it in a standalone player, it
usually looks better. I have no idea how that even works, except that
perhaps PyKaraoke interprets CDG instructions strictly and maybe some of the
commercial players are "looser" with the spec.
The only fixes I know of are to try to slow down the reading process, try a
different drive, or retry with the disc repeatedly until you get better
results.
--
William W. Ferrell
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Pykaraoke-discuss mailing list
Pykaraoke-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pykaraoke-discuss
