I ripped 2 different copies of 10,000 Maniacs: MTV Unplugged (1994) [40183-6]

I wanted 3 to be sure, but 2 rips were identical (and I was becoming anxious to see if a repaired player would work

I used some resources here to aid in this, so I thought I'd share a basic tool I used for verification. It's the same concept as AccurateRip for CD's, which is hashing. I read for hours on optical and coaxial sp/dif and at no point did I find a mention of any parity or parity like features, so even if you don't detect digital silence or broken frames or pitch jumps or whatever you define to search for... there seems to be no way to actually verify bit perfect. Apparently it's even questionable enough with CD's to the point of the invention of AccurateRip and CD's have some matrix checking. I'm in no way implying these hashes are needed or anything like that, it's just my preference and I didn't see it anywhere else (for LaserDisc). Also, if you're one of those people that have likae $5000 LD setup, don't you want to really be sure your audio is perfect? I mean, rrrrrrrrrrrrreeealllllly sure?

I AM NOT A PAID PROGRAMMER AND I'M ABSOLUTELY NOT PYTHONIC

The main script is "maniacs.py". On Linux or Mac you can invoke the GUI "maniacs_gui.py" if you have python and the tk related kit. I'm assuming if you're a Linux/Mac user you can manage. I assume nothing for Window's users so there is a "maniacs_gui.exe" that worked on Win7 and Win10.

https://download1492.mediafire.com/irf4 ... helper.zip

By default, it picks 2 seconds from the start of the file to start hashing, all the way to 2 seconds before the end. It copies 176400 at the start of hashing process so it can later find the same place to start when verifying the hash.

Assuming you've just ripped a .wav and somebody gave you a sample file or you created it yourself, here's a screenshot of the throw away gui...


It's basic, but it does hash both the sample and the payload. To create a sample file, you use the "Create" tab, load a source file, and hit GO! The default name is "$source_filename.json". Note: both the "Match" and "Create" hashing/sample generation functions is basic file offsets and matching said offsets, so they can be used with any type of file.

Calibrating bit perfect is very simple. Find any audio CD and rip a track to on your PC using cdparanoia, EAC, CueTools or whatever. Note that the type of disc does not matter as long as there's data coming through the optical port, you don't need any special disc and you can technically use a DVD (but in 48000hz). Now, play the CD in your player and capture a few seconds of the audio. Then, you'll create a sample off of those few seconds you record in "create". Finally in "Match", pick the full audio track you ripped off the CD for "source" along with the sample you just created and hit GO! At the end it will print "OK" or "BAD" (green or red). If it's "BAD" one side wasn't bit perfect.

To record the bit perfect stream on your PC, you can use this hardware (it's exactly what I used)...

https://www.ebay.com/itm/401755911322

It's $12usd on e-bay (a seller on AliExpress had it for 9...I can't find the link now :-/).

Side note: this TOSLINK<->OPTICAL adapter did _NOT_ work, I tested it for the heck of it, it did _NOT_ work.


Software to record is simple. If you can get a USB stick and flash Linux onto it, it's this easy after typing "alsamixer" into the shell... picture says it all (but it's device specific). This is what I used to capture 10,000 Maniacs MTV Unplugged (although I would of like a couple things more secure in ALSA).


There's a couple things with the little tool I'd like to add, but my math skills are < 0. For instance, a hash value every 88200 bytes. This would increase the sample.json file by a couple megabytes but it could come in handy for disc rotted rips. Also another basic seeking operation to skip all digital silence at the beginning and end of the file. I had that already in there once but, I deleted it and don't remember why.

I bought and tried this other audio hardware for this rip (along with a slew of cables):

USB 1.1 based Creative Extigy: I couldn't get it to work with anything other than WinXp and even then I could only enable the coaxial input, ONLY ENABLE because it never worked :-/. Under Linux it loads up and apparently somebody programmed it's own mixer software, maybe they did this back from the OSS days but I couldn't get it to capture anything but silence with a little random noise now and then. I didn't try Mac

Avid DigiDesign 002 Rack: Works fine on Win10 as a sound device (although ironically no so much in ProTools 12.5). Sadly, it's HUGE and it's firewire, so it's going to be donated to a thrift store. It also worked under MacOS just fine. I didn't try Linux.

Focusrite Sapphire Pro 24: A very big let down. The mixer software always seems to apply some sort of processing (dither?). No matter what I tried, the recording was never bit perfect.



Here's the help:



A sample of what the .json file looks like:

Here's how you setup Reaper for audio capture. NOTE: to create a new track, double click in the left blank area... the place where you see a track already added on the left. You also have to click the red button to enable it. You lastly need to set the channels, see where it says "Input 1+Input 2".

To answer your question: no. I don’t care if my audio is bit perfect. No matter how much I spend on my setup I’m not putting myself through that sort of OCD hell.

Furthermore, the point of an audio fan buying better gear is that they can tell it’s good by using it. A test pattern is one thing but I know my stuff is good or not when I hear it. A computer file that claims to prove this one way or the other…it carries no weight. Computers can record but they can’t hear. Hearing is a psychological process. It requires an IQ, which computers don’t have. I’m just as well off measuring all my RCA cable ends to make sure they are perfectly round…

I've had a go at similar before and had good results. Here's how I got on if it helps you at all.

Zoom U-44

That was the 1 device I kept going back to in temptation. It was way too high $$ for the job but I like it's options and the fact that it's very small for all it has. It also looks like it could be converted to some kind of sci-fi handheld portable, ever seen Ziggy's thing in Quantum Leap?. Out of all the devices I saw, if one of them was the mini-nuke of recorders, it would be that.

I'm pretty sure I have a bit perfect rip... pretty sure. Of the 2 discs, 1 disc apparently ripped fine the first time but the other I had to rip 2 times to get a matching hash. I ripped it a 3rd time just to be sure and it matched again. The odds on getting matching hashes (sha3 256) off of 2 discs is pretty insane so... I'm pretty sure .

What I couldn't decide on when hashing was where to start and where to stop. 10,000 Maniacs MTV Unplugged has a publisher card at the beginning with a sound effect. I can imagine many discs do and some probably have something similar at the end. I decided to record all audible sound to make it simple, minus 4 seconds, 2 in front, 2 in back. That's not so great though as I personally don't consider those publisher cards of interest to me, in fact after hashing I cut it out (it added ~8 seconds).


The biggest headache I had was finding a 2nd piece of software that would rip perfectly :-/. Linux's ALSA is no surprise, but Reaper was to me. While Repaer may not be what I'll use, I have to say that everyone was right in that it does do the job. I was surprised Audacity doesn't seem to do it. Pro Tools doesn't seem to either but I'm not surprised there as that software has a large envelope/chain.

Glad you were able to achieve what you were set out to do.
I know I've read Ted's post about the zoom once and bought something else that another poster here said to get for capture but
I think it captured at lower quality, I tried it once for 5 minutes and it worked but can't remember the quality, really wanted it to rip
and post an LD which is rare but never got around to it.

Nice work! Check out Bit Perfect, similar concept but it checks each sample value of the audio.

How does it check each sample? I saw that before I wrote the script but, I couldn't understand how it works. If the programs source was available, which I couldn't find, that would be helpful. Regardless though, without actually using the human ear + a consistent hash value, you really don't know. Well, maybe you do and I'm sure most captures do come out perfect but, without a numeric baseline and a human perspective...??? The rule of AccurateRip is that if it sounds right to many people and many people have the same hash value, then it's correct. The man+machine tandem.



You mean for RCA capture? I know a long time ago when I captured cartoons that grounding was paramount before all else. I'm sure if you want a very high quality rip then multiple pieces of hardware are involved, although I imagine diminishing returns will kick in very quickly. As for digital capture, that cheap CMedia based card is all anyone needs. It's hard to beat at it's price, especially as it comes with an optical and USB cable!! Warning though, I could _NOT_ get it to output optical at anything other than 48000.

You are overthinking this. CD and LD audio is made up of samples, precisely 44,100 of them a second. Each sample is just a 16-bit integer (whole number), ranging from 0-65,536. If you match 10 seconds of audio, that's 441,000 numbers in a row that have to exactly match. Think of a lotto person drawing 441,000 balls for the days lotto number, and there's 65,536 balls in the basket for them to choose from. That is how the app works, it goes sample by sample and checks each one like you would your lotto ticket. There's no room for ambiguity.

When you rip audio CDs there is a chance that the built in error correction won't be enough (say a bad scratch or ding), and it'll give you back a bad sample value. That is where those ripper tools come in handy. You can see if the hash of the file you ripped matches someone else's to know if there's any imperfections in your disc. That is very different than checking the samples, since you'd have to share the original audio to verify it that way.

Edit: Edited for clarity, also wanted to say nice find on the cheapo device!

Sure, but I only care about the overall payload that is recorded from the disc player. I don't know how BitPerfect helps me with knowing that. I only care how it sounds to me and that it has a consistent hash. To be clear, I only care about the hash so that the file stays in tact and is replicable to combat bitrot or file corruption or whatever. Again, capturing from a LaserDisc player offers no securities and could very well be a tiny bit corrupt in an unnoticeable manner, similar to UDP. Is it a great big deal, no, but if it can be combated with minimal effort, why not.

As for BitPerfect, is this supposed to fail? It's the second half of the source file.

A recording can have deadspace/garbage on either side, but the reference shouldn't.

Say your reference file is the sequence

1 5 3 5 6

and your recording is:

9 9 1 5 3 5 6 9

It will find the match in there. You may want to try increasing the edge tolerance to 2-3% to see if that helps. It is to help with some weirdness I've found where the first few samples the player reports back aren't quite perfectly in time. In that example, it would shave off the 1 and 6 and try to match to

5 3 5

Hope that makes sense.

Edit: For an analogy, say you wanted to see if your friends copy of a book matches your copy. Bit Perfects method is to go through every word in your copy (reference) and make sure it appears in the same sequence in the friends (recording). The method you are using would be like generating the summary on the back of the book, and comparing that. Seems hard to use since your recording couldn't have any junk on either side of the payload, otherwise your summary (hash) will be generated differently. That is probably why you are only getting matches sometimes with it.

It does, that's similar to the "Stitch" option I wrote for joining 2 sides together if a match is found by removing leading and ending junk. Here's a visual of that (the GIF might not loop without opening in it's own window, takes 5 seconds to start the animation).



Here's a visual of creating a sampling...



I can't match byte to byte because I don't know what the captured file is supposed to be from the LD player or if it's even correct until I match it at least twice. Hashing allows me to do that without having to keep all copies of the file on hand at all times. I could create some routines to check for certain anomalies besides drop outs, but I'm not good with math and the complexity is unwarranted as the recorder will still keep correct time. Now the "Match" function could match byte for byte by changing the loop from feeding chunks to the hashing function to simply matching the other file but, it doesn't do me any good outside of matching the sample (again, I don't know that what is captured is correct at that point).

If you ever find the source post a link as I'd like to see more of what you're talking about as it seems I'm misunderstand the extent of the program.

Sorry but I'm really confused what your use case is here. Most people are just running this app once to verify that their capture chain is setup correctly. You say you can't match byte to byte but that is the whole point of the reference file - we know EXACTLY what the bytes are. Why are you keeping hashes of ripped files?

I was confused too. I thought that program detected drop outs or more immediately important, digital silence. Anyways, the script can of course calibrate, from my first post...

In a nutshell the purpose is AccurateRip. It's not too hard to match 2 different hashes from 2 different discs to prove you've ripped successfully.

With the sha3-256 hash, it's many, _MANY_ more times likely that you'll experience bitrot on your HDD or a corrupt filesystem of some sort than finding a collision. Basically, 2 rips with 2 identical hashes is probably all you need!!! Just 2!! However, you can't do it without at least 2 (I prefer 3, but I can't find a 3rd to buy yet, but I'm pretty sure it's good as is).

I'm only going to add a couple more things to this and I'm done. Again, without some of the helpful information here by members (I did some serious information hunting+gathering here ), I don't think I would of bothered with the ripping, so I'm putting it here as it worked for me. Use or don't, maybe it will give someone else an idea or not. I didn't make it for any other purpose than aiding myself in ripping this title. Now that it's done, the last few things I add will be more for someone else that is curious than it will be for myself.

___PS___ does anyone know how to detect digital silence outside of looking for null? I have 2 seconds of what sounds like silence to me that has repeating values like this...

\xfd\xff\xfd\xff\xfb\xff\xfc\xff\xfc\xff\xfc\xff\xfc\xff\xfd\xff\xfc\xff\xfc\xff\xfc

but then later on it becomes a bit more erratic...

\x00\x10\x00\x15\x00\x03\x00\x15\x00\xff\xff\x1d\x00\x05\x00

I can't find a code example of how to do this. There used to be an example in cdrtools by Jörg Schilling but, either I'm blind or it was removed.

I see, so you are ripping multiple copies of the same disc to prove there are no defects? That test in itself won't prove your capture setup is bit perfect however.

If you are worried about long term storage I'd recommend checking out the ZFS filesystem. It does parity checks when writing to and reading from it, pretty much guaranteeing data integrity.

If the goal is a bit perfect audio rip from LD then I'd say the Doomsday Duplicator is the way to get that. EFM decoding has been sorted out and will be perfected soon if it isn't already. That way you get the PCM from the RF stream directly. I can't fathom a better way to preserve and/or rip the audio from a LD.

But if you simply want to capture out of a player's digital outputs then I'd be looking at interfaces by Lynx or other serious manufacturers who are known for precise clocking. It would be ideal to have a word clock connection but LD doesn't have that.

I'm also not 100% certain but I think the sample rate is actually 44.056 on LD and most consumer DACs report it as 44.1

I'd like to actually confirm that somehow.

There may be a few players with AES outputs (EAD, Faroudja, Runco) but I doubt that will make any difference in the capture.

I'd like to confirm a lot of things .

Unless I'm missing something, you can confirm it's 44100 by the fact that the time doesn't drift. For example, stereo, 16bit, but it's really 44056 in disguise. After 1,003 seconds the period would drift by 44132 samples, that's over a second, which would seem very noticeable. That's just after 1,003 seconds, after a hour the drummer is going to be hitting the symbols 3.5 seconds early... would be interesting Of course this requires video to kind of confirm the timing, but... There's seemingly a lot of ways to proof.

I'd REALLY like to know how PCM was mastered and split to put onto both sides of a LaserDisc. For instance, my script has a stitching feature that I don't think will ever work . It shuffles bytes from the end of side A to match bytes from the beginning of side B, dead basic stuff. Assume it *should* work because both sides have a overlap of 5 seconds, I don't know if it would because of the software and/or software processing like dither. Sure the 5 seconds *sounds* identical, but to the computer it isn't. Sadly the the disc of interest, 10,000 Maniac MTV Unplugged, has a fade out on side A and a fade in on side B. There's about .5 seconds of what sounds identical, but not to the computer (I can still stitch there, but I have to manually :-*(

Lastly, there was/is a lot of grey smoke around the device to use. If you've read in people's post that you really only need the most basic hardware, they were right. If you rip something twice, and it's identical twice, it's almost certainly correct. You don't need a certain brand name or price point, you simply need a decent enough chipset and not-so-crappy design, cmedia's stuff is perfectly fine.