03223: mach3: MACH 3 "disc error... stay put!" laserdisc audio decoding problem during fighter game

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03223	Gameplay	Minor	Always	May 30, 2009, 20:58	Dec 24, 2009, 13:35

Tester	bit0mike	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows XP/Vista/7 32-bit
Status [?]	Confirmed			Driver	gottlieb/gottlieb.cpp
Version	0.131	Fixed in Version		Build	I686
		Fixed in Git Commit		Github Pull Request #

Summary	03223: mach3: MACH 3 "disc error... stay put!" laserdisc audio decoding problem during fighter game
Description	During the fighter game (vs the bomber game), about halfway into the game, "disc error... stay put!" appears for about 10 seconds, disappears for 15-20 seconds, appears and disappears again, then game continues correctly to the end. The bomber game is not affected. My guess is there were some small scratches on the laserdisc that the CHD was created from, causing a bit of static in the audio. Since MACH 3 stores the target data as tones on the right analog audio track of the laserdisc, the game will error out momentarily in the presence of excessive audio static.
Steps To Reproduce	Enable infinite lives dipswitch, coin up, start fighter game, wait just over 6 minutes. If you put the game into service mode via F2, go to Video Tests (5), then Audio Track Decoder (4), then checksum test (1) you can test the logic that decodes the tones on the right audio track to data. There are a few sporadic errors throughout the disc, but between frames 13200 and 13600 the error counts jump up significantly, plus a little bit of picture noise in the top 1/5 of the screen... which is why I figured there's a scratch on the original.
Additional Information	I have a good quality MACH 3 laserdisc, so if someone can point me to some CHD tools that'd let me replace the audio portion of the CHD with my own .wav from my own disc just for testing... Hopefully in the next week or two I'll have my MACH 3 motherboard repaired so I can do side-by-side video comparisons between original hardware and MAME
Github Commit

Flags
Regression Version
Affected Sets / Systems	mach3

Attached Files	0000.png (588,367 bytes) May 31, 2009, 05:36

No.04425 Fujix Administrator May 31, 2009, 05:37 edited on: May 31, 2009, 05:38	Confirmed the problem and added a screenshot.
No.04437 Gyrovision Tester Jun 2, 2009, 08:16 edited on: Jun 2, 2009, 08:35	I am unable to test this in MAME, but years ago in another emulator I discovered you will also get the "Disc Error .... Stay Put!" message in consistent areas of the game when running ONLY the ROMs. See if you can get only the ROMs to run and play through fighter and bomber games and see if the Disc Error message comes up. If it does, the problem is elsewhere.
No.04440 bit0mike Tester Jun 2, 2009, 22:27	The coordinates for the targets you're supposed to shoot at in the game are stored in the right audio track on the laserdisc, so yeah, it'll continually report disc errors (really "unable to get the coordinate data" errors) if there's no disc. That's expected.
No.04441 Gyrovision Tester Jun 3, 2009, 00:23 edited on: Jun 3, 2009, 00:29	Do you get disc errors in exactly the same areas of the game with or without the disc? Do the errors appear intermittently? In Daphne the disc errors would show up in the exact same places in the game, with or without the disc, about halfway into the game. I'm just wondering if this is also happening in MAME.
No.04447 bit0mike Tester Jun 3, 2009, 19:09	exactly the same area. And there's some video distortion in the spot, visible in the above screenshot, that's why I think it's a scratch on the disc the CHD was made from, not a bug in the driver. Look just below the cloud on the right, about 1/3 of the way between the top of the screen and the top of the mountains, you'll see some slightly distorted horizontal lines. FWIW my real hardware does the same thing halfway through the bomber game due to a scratch on my disc. The quick way to check of course is to run the same audio checksum test on usvsthem, which is the same hardware. I'll do that tonight.
No.04452 bit0mike Tester Jun 4, 2009, 20:44	...or not, because usvsthem's right audio track doesn't seem to have data on it like mach3's does. I'm sampling my mach3 disc's audio tracks into a 48khz wav now. Between the mame one and mine it should be possible to edit together a good one w/ something like audacity.
No.04505 bit0mike Tester Jun 15, 2009, 02:34	Still looking into this one, just for fun. I extracted the 48Khz stereo WAV out of the CHD (extracted the AVI first, then the WAV from that) and loaded it up in Audacity, and there's definitely some spikiness/noise in there at around frame 13200. I also dug up the old m3target.bin that was used by older versions of MAME that didn't even support laserdiscs correctly -- and wrote a simple Perl script to step through each data frame, validate the start-of-frame markers, frame numbers, and all of the checksums. It passes. Then with the MAME 0.132 source, I modified gottlieb.c to have the current MAME log all the bytes decoded (forcing logit to 1 in laserdisc_audio_process()), started the game, ran the audio checksum test in the game's service menu to force it to read the whole disc, pulled the hex bytes out of the logfile and dumped it to a binary file w/ another Perl script... in essence attempting to re-create an equivalent m3target.bin so I could run the same checksum tests. The result was a LOT of checksum errors. Most start at exactly frame 13198, but there are a lot of others scattered randomly throughout the file. It might be that getting a "perfect" audio rip of this disc is not realistic (though as far as I know it's the only laserdisc game that even cares, so even if so it's still a one-off for just this game) so maybe tweaking the zero crossing detector code in gottlieb.c is the way to go. I may experiment w/ that over the next few weeks, meanwhile if anyone wants my Perl code to try themselves, ask.
No.04512 Haze Senior Tester Jun 15, 2009, 10:03	if the audio data is meant to be digital, then it sounds like a situation where having multiple dumps from multiple discs would help verify the situation. right now there is clearly a problem, and the CHD should be marked as bad. Obviously with these things there has to be a tolerance for fault / scratched LDs causing slight visual and audible artifacts, but when it's causing part of the game to be completely missing the problem is severe enough to flag IMHO.
No.04515 bit0mike Tester Jun 16, 2009, 01:14	The audio data on this laserdisc is analog, there aren't any digital audio tracks on it. If there were, it'd be trivial to copy/paste any degraded sections from one disc dump to another disc dump using Audacity, Pro Tools, Garageband etc. As it is, I do have a 48Khz dump of my disc that I've edited down so it starts in exactly the same spot (down to the byte) as the CHD's copy, however the ending is about 2 seconds off, probably because of slight clock variation between whatever sound card was used vs mine. That makes repairing one set from the other pretty difficult; you'd have to go in and hand-edit individual samples one at a time to remove the impulse noise. Plus my dump is not perfect either -- on my real Mach3 machine, it gives the exact same "disc error.. stay put" much later in the game (frame 40,000 or so). I think first I need to pull the zero-crossing code out into something that can just run on a standalone .wav file so that I can experiment w/ either the code or with hand-editing the samples. Might take me a while. :) On the off chance that the zero-crossing code can be improved without resorting to editing (or FFT-filtering) the original, I'd argue against marking the CHD bad for now.
No.04516 Haze Senior Tester Jun 16, 2009, 07:44	ah, ok, I thought it was digital data stored in an analog form (such as cassette based games) due to the checksumming you mentioned.
No.04520 bit0mike Tester Jun 17, 2009, 08:15	it is... I thought you were asking about which pair of the 4 audio tracks on a laserdisc it was using. Oops. Anyway, it looks similar to FSK encoding, with 10khz being the 1 tone and 5khz being the 0 tone, and beween 1Kbyte blocks there's a 2.5khz gap tone so it can get back in sync if there's an error. There are some other frequency peaks in there but I think they're just harmonics. I have the relevant part of gottlieb.c split out into a little (embarassingly hackish) command-line tool that'll take the .wav extracted from the .avi extracted from the .chd... peel off the right audio channel, and try to output the decoded bits to a binary file. Still experimenting with adjustments to both the C code and the .wav to see how best to get the error rate down (the schematics of the game indicate it's got a 20khz lowpass filter, though a 1khz-10khz bandpass filter helps more).
No.04551 bit0mike Tester Jun 23, 2009, 17:10	OK, I now have a repaired .wav file that can be used to replace the audio in the .avi inside the .chd. This was tediously edited by hand, rather than running bandpass filters etc on it. I used virtualdub to replace the avi audio with this new wav, then used chdman to build a new .chd from that avi, and now the game plays great and the audio checksum selftest (mostly) passes. I say mostly because there are still a few single errors here and there... but most of them occur on my own laserdisc in the exact same spots... so there may be a mastering error. And there are one or two other clipped waveforms I wasn't able to find. But all the remaining errors are generally single-bit flips and so are just single-frame errors, rather than causing the game to lose sync entirely as was happening before. You can probably use Audacity or a binary diff to compare the two .wav's. The .wav is temporarily at http://lastnightspants.com/mach3tmp/mach3cleaned.zip as it's 300MB zipped and too large to attach here. I did try just sampling my own disc and doing copy/paste of sections of audio, however even when the start of the audio was lined up perfectly, my copy still ran 1-2 seconds longer, probably because the clock on my sound card runs slightly slower than the clock on Aaron's, or maaaybe the Pioneer LDP-1100 or Sony LDP-2000 I used were playing at 30fps instead of 29.97fps, but anyway, that's why I couldn't just easily replace parts of the original rip with parts of mine. So the hand-edited version isn't necessarily "perfect" from a preservation standpoint, vs just capturing another cleaner disc. That's kind of a philisophical discussion though :) See also comments on ticket 03189 for another, simpler, issue w/ this game
No.04663 aaron Developer Jul 20, 2009, 06:49	How much did you hand-edit? And was it spot fixes or heavy-duty reworking of the affected areas?
No.04707 bit0mike Tester Jul 26, 2009, 04:54	Spot fixes on a few hundred samples across the whole disk, most of them in the affected Note: 01000 frames, basically squaring off "dents" in the waveforms. You can probably binary-diff the .wav above with a .wav extracted from the chd to see how many changes there were. Algorithmically redoing whole sections (with, say, low-pass and high-pass filters) didn't end up working out so well...
No.05305 Haze Senior Tester Dec 24, 2009, 13:35 edited on: Dec 24, 2009, 13:37	did anyrthing come of this? it's a shame having 20gig laserdisc CHDs where parts of the game are still unplayable due to errors in them, or the decoding of them. Given that the original source is analog (and thus somewhat lossy) anyway, I don't think using hand-repaired data until a better disc is found is too bad?