LaserDisc Database :: View topic - 10,000 maniacs mtv unplugged audio bit perfect test

Code: Select all

positional arguments:
  match || create || overlap || stitch
                        one of these is required

Match and Create:
  -i SOURCE_FILE, --source_file SOURCE_FILE
                        source file to match or create against
                        default: "source.wav"
  -j JSON_FILE, --json_file JSON_FILE
                        json file with values to use
                        default: "$source.json"
  -m SAMPLE_FILE, --sample_file SAMPLE_FILE
                        the sample filename to use
  -u HASH_ALGORITHM, --hash_algorithm HASH_ALGORITHM
                        use this hash algorithm
                        default: "sha3_256"
  -t CHUNK_SIZE, --chunk_size CHUNK_SIZE
                        read and write in this chunk size
                        default: 4096

Create:
  -s NEW_SAMPLE_OFFSET, --new_sample_offset NEW_SAMPLE_OFFSET
                        offset to create sample in source file
                        default: 352800
  -n NEW_SAMPLE_SIZE, --new_sample_size NEW_SAMPLE_SIZE
                        size for NEWLY CREATED samples
                        deafult: 176400
  -e SOURCE_END_OFFSET, --source_end_offset SOURCE_END_OFFSET
                        offset to STOP hashing the source file
                        NOTE: measured from end of file
                        default: 352800
  -c COMMENT, --comment COMMENT
                        Elektra Entertainment 40183-6
  -d DESCRIPTION, --description DESCRIPTION
                        10,000 Maniacs - MTV Unplugged (1994)
  -v LD_ID, --ld_id LD_ID
                        an id for the LaserDisc, ie. 08952
  -l DECODE_SAMPLE, --decode_sample DECODE_SAMPLE
                        decode a sample in a json file
                        default: "decoded.sample"
                        NOTE: obvserves -m switch, ignores others

Overlap and Stitch:
  -a SIDEA, --sidea SIDEA
                        side A filename for overlap/stitch
                        default: "sidea.wav"
  -b SIDEB, --sideb SIDEB
                        side B filename for overlap/stitch
                        dafault: "sideb.wav"
  -p OVERLAP_BYTES, --overlap_bytes OVERLAP_BYTES
                        bytes to match for overlap
                        default: 11025
  -q OVERLAP_A, --overlap_a OVERLAP_A
                        total bytes to search A for an overlap
                        default: 1940400
  -r OVERLAP_B, --overlap_b OVERLAP_B
                        total bytes to search B for an overlap
                        default: 1940400
  -z NUM_OF_PROCESSES, --num_of_processes NUM_OF_PROCESSES
                        number of processes to use for overlap search
                        default: all CPU threads (4); max_procs: 32
  --stagger STAGGER     amount of bytes to stagger in an overlap search
                        default: 33 (1 data frame)
                        Note: the smaller, the more exhaustive/slower

Stitch:
  -o OUTPUT_FILENAME, --output_filename OUTPUT_FILENAME
                        when stitching, the output filename
                        default: "stitched.wav"
  -f SIDEA_STITCH, --sidea_stitch SIDEA_STITCH
                        stitch side A at this offset
                        default: -1 (disabled)
  -g SIDEB_STITCH, --sideb_stitch SIDEB_STITCH
                        stitch side B at this offset
                        default: -1 (disabled)
  --ignore_header       skip header checks and modifications

Match:
  -k SOURCE_START_OFFSET, --source_start_offset SOURCE_START_OFFSET
                        offset to START searching the source file
                        default: 0
  -w SSF_OFFSET, --ssf_offset SSF_OFFSET
                        offset to start at inside of an EXISTING sample
                        (trims bytes from the start of the sample for searches)
                        default: 0
  -x PAYLOAD_BYTES, --payload_bytes PAYLOAD_BYTES
                        override the amount of bytes to hash

Other:
  -y, --gui             change stdout of overlap search for GUI
                        (uses '\r' to overprint lines for proc status)

    
    In general, supply a sample to find in a file and if the
    sample is found, the starting offset of where it was found
    is used as the starting position to hash X amount of bytes.
    
    
    match
    Match a sample within a file.

      ./maniacs.py match -i source.wav -j "sample.json"

    Searches "source.wav" using the file "sample.json".
    If a match is found, the starting offset will be displayed.
    If a json file with values is also specified, and the json
    file has the total bytes hashed, a hash will be calculated.
    If there is a hash value in the json, it will be compared.
    NOTE: A json file isn't required to find a matching offset.
          However, by default, the sample is assumed to be in a
          json file. Using -m will override that behaviour. If
          -m is absent, the default name is $source.json
    NOTE: Both Match and Create work generically on any file
          so, the file can be anything.
    NOTE: The -m switch can be used to use a raw, decoded
          sample. ie. -m "decoded.sample" instead of using the
          base64 encoded sample within sample.json.
    
    
    create
    Create a new sample along with or in a .json with values.

  ./maniacs.py create -i source.wav -s 352800 -e 352800 -n 176400
      
    The above creates the sample file named "source.wav.json". 
    It starts hashing the payload 352800 bytes from the start
    of the file (-s) and ends 352800 before the end of the file
    (-e). The sample size created (-n) is 176400 bytes.
    Note: these values are default, so leaving off -s, -n, and
    -e creates the same json file. Inside that json might
    look like this (comment and description are not required):
    {
      "comment": "sample starts right after the piano starts",
      "description": "10,000 Maniacs - MTV Unplugged (40183-6)",
      "hash_algorithm": "sha3_256",
      "ld_id": "1 (or some number maybe?)",
      "payload_bytes": 734856,
      "payload_hash": "f4726574c8cf...",
      "sample_hash": "a38d7d9aeda5...",
      "zzz_sample_base64": "Base64EncodingOfSampleFile..."
    }
    By default, the json file will be named $source.json, use
    -j filename.json for a different name. Use -m to save the
    sample to its own file and not bas64 encoded in the .json.
    The -c -d and -v switches add a comment, description, id.
    ./maniacs.py create -i source.wav -d "10,000 Maniacs..."
    NOTE: The raw data in the sample.json can be decoded from
          base64 to a file with the -l switch:
          ./maniacs.py create -l sample.json -m sample.decoded     
    NOTE: Both Match and Create work generically on any file
          so, the file can be anything.
    
    
    overlap (slow)
    Find where 2 files overlap.

      ./maniacs.py overlap -a sidea.wav -b sideb.wav
      
    Searches the end of side A to find a match at the beginning
    of side B. If using 1 thread, slowness may be intolerable.
    NOTE: By default the search routine spawns 1 process for
          each CPU thread. Use -z 0 to use only 1 CPU thread.
          ./maniacs.py overlap -a sidea.wav -b sideb.wav -z 0
    NOTE: As with Match and Create, works with any file types.
    
    
    mode: stitch
    Stitch 2 files together at an overlap.
    
    ./maniacs.py stitch -a sidea.wav -b sideb.wav -o stitched.wav

    Same as overlap but, also stitches the 2 files together at
    the overlap if an overlap is found. Use -o to set an output
    filename. The default filename is "stitched.wav".
    The -f and -g option can be used to stitch files together
    without searching for an overlap but, both offsets must be
    supplied.
      ./maniacs.py -a sidea.wav -b sideb.wav -f 2188975 -g 293934
    NOTE: The value used with side A via the -f switch is how
          many bytes to copy starting at the beginning of A.
          The value for the -g switch is how many bytes to skip
          at the beginning of side B.
    NOTE: If the source files are RIFF but the resulting file
          will be > 4GB, then the file will be saved as RF64.
    NOTE: Meta tags will be lost.
    NOTE: By default this requires a RIFF or a RF64 header for
          side A. Side B is blindly copied so side B can be
          any file type. Use --ignore_header to ignore the
          header in side A and blindly copy side A aswell.
          

Author:	spiderfood [ 20 Jan 2023, 08:46 ]
Post subject:	10,000 maniacs mtv unplugged audio bit perfect test
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... Attachment: gui_example.jpg [ 169.54 KiB \| Viewed 3389 times ] 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)... Attachment: 6 Channel 5.1 External USB Sound Card Adapter Optical Audio Laptop Notebook PC.jpg [ 222.08 KiB \| Viewed 3389 times ] 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. Attachment: optical_toslink_adapter.jpg [ 240.58 KiB \| Viewed 3389 times ] 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). Attachment: help_alsamixer.jpg [ 262.18 KiB \| Viewed 3389 times ] 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. Attachment: hardware.jpg [ 342.05 KiB \| Viewed 3389 times ] Here's the help: Code: Select all positional arguments: match \|\| create \|\| overlap \|\| stitch one of these is required Match and Create: -i SOURCE_FILE, --source_file SOURCE_FILE source file to match or create against default: "source.wav" -j JSON_FILE, --json_file JSON_FILE json file with values to use default: "$source.json" -m SAMPLE_FILE, --sample_file SAMPLE_FILE the sample filename to use -u HASH_ALGORITHM, --hash_algorithm HASH_ALGORITHM use this hash algorithm default: "sha3_256" -t CHUNK_SIZE, --chunk_size CHUNK_SIZE read and write in this chunk size default: 4096 Create: -s NEW_SAMPLE_OFFSET, --new_sample_offset NEW_SAMPLE_OFFSET offset to create sample in source file default: 352800 -n NEW_SAMPLE_SIZE, --new_sample_size NEW_SAMPLE_SIZE size for NEWLY CREATED samples deafult: 176400 -e SOURCE_END_OFFSET, --source_end_offset SOURCE_END_OFFSET offset to STOP hashing the source file NOTE: measured from end of file default: 352800 -c COMMENT, --comment COMMENT Elektra Entertainment 40183-6 -d DESCRIPTION, --description DESCRIPTION 10,000 Maniacs - MTV Unplugged (1994) -v LD_ID, --ld_id LD_ID an id for the LaserDisc, ie. 08952 -l DECODE_SAMPLE, --decode_sample DECODE_SAMPLE decode a sample in a json file default: "decoded.sample" NOTE: obvserves -m switch, ignores others Overlap and Stitch: -a SIDEA, --sidea SIDEA side A filename for overlap/stitch default: "sidea.wav" -b SIDEB, --sideb SIDEB side B filename for overlap/stitch dafault: "sideb.wav" -p OVERLAP_BYTES, --overlap_bytes OVERLAP_BYTES bytes to match for overlap default: 11025 -q OVERLAP_A, --overlap_a OVERLAP_A total bytes to search A for an overlap default: 1940400 -r OVERLAP_B, --overlap_b OVERLAP_B total bytes to search B for an overlap default: 1940400 -z NUM_OF_PROCESSES, --num_of_processes NUM_OF_PROCESSES number of processes to use for overlap search default: all CPU threads (4); max_procs: 32 --stagger STAGGER amount of bytes to stagger in an overlap search default: 33 (1 data frame) Note: the smaller, the more exhaustive/slower Stitch: -o OUTPUT_FILENAME, --output_filename OUTPUT_FILENAME when stitching, the output filename default: "stitched.wav" -f SIDEA_STITCH, --sidea_stitch SIDEA_STITCH stitch side A at this offset default: -1 (disabled) -g SIDEB_STITCH, --sideb_stitch SIDEB_STITCH stitch side B at this offset default: -1 (disabled) --ignore_header skip header checks and modifications Match: -k SOURCE_START_OFFSET, --source_start_offset SOURCE_START_OFFSET offset to START searching the source file default: 0 -w SSF_OFFSET, --ssf_offset SSF_OFFSET offset to start at inside of an EXISTING sample (trims bytes from the start of the sample for searches) default: 0 -x PAYLOAD_BYTES, --payload_bytes PAYLOAD_BYTES override the amount of bytes to hash Other: -y, --gui change stdout of overlap search for GUI (uses '\r' to overprint lines for proc status) In general, supply a sample to find in a file and if the sample is found, the starting offset of where it was found is used as the starting position to hash X amount of bytes. match Match a sample within a file. ./maniacs.py match -i source.wav -j "sample.json" Searches "source.wav" using the file "sample.json". If a match is found, the starting offset will be displayed. If a json file with values is also specified, and the json file has the total bytes hashed, a hash will be calculated. If there is a hash value in the json, it will be compared. NOTE: A json file isn't required to find a matching offset. However, by default, the sample is assumed to be in a json file. Using -m will override that behaviour. If -m is absent, the default name is $source.json NOTE: Both Match and Create work generically on any file so, the file can be anything. NOTE: The -m switch can be used to use a raw, decoded sample. ie. -m "decoded.sample" instead of using the base64 encoded sample within sample.json. create Create a new sample along with or in a .json with values. ./maniacs.py create -i source.wav -s 352800 -e 352800 -n 176400 The above creates the sample file named "source.wav.json". It starts hashing the payload 352800 bytes from the start of the file (-s) and ends 352800 before the end of the file (-e). The sample size created (-n) is 176400 bytes. Note: these values are default, so leaving off -s, -n, and -e creates the same json file. Inside that json might look like this (comment and description are not required): { "comment": "sample starts right after the piano starts", "description": "10,000 Maniacs - MTV Unplugged (40183-6)", "hash_algorithm": "sha3_256", "ld_id": "1 (or some number maybe?)", "payload_bytes": 734856, "payload_hash": "f4726574c8cf...", "sample_hash": "a38d7d9aeda5...", "zzz_sample_base64": "Base64EncodingOfSampleFile..." } By default, the json file will be named $source.json, use -j filename.json for a different name. Use -m to save the sample to its own file and not bas64 encoded in the .json. The -c -d and -v switches add a comment, description, id. ./maniacs.py create -i source.wav -d "10,000 Maniacs..." NOTE: The raw data in the sample.json can be decoded from base64 to a file with the -l switch: ./maniacs.py create -l sample.json -m sample.decoded NOTE: Both Match and Create work generically on any file so, the file can be anything. overlap (slow) Find where 2 files overlap. ./maniacs.py overlap -a sidea.wav -b sideb.wav Searches the end of side A to find a match at the beginning of side B. If using 1 thread, slowness may be intolerable. NOTE: By default the search routine spawns 1 process for each CPU thread. Use -z 0 to use only 1 CPU thread. ./maniacs.py overlap -a sidea.wav -b sideb.wav -z 0 NOTE: As with Match and Create, works with any file types. mode: stitch Stitch 2 files together at an overlap. ./maniacs.py stitch -a sidea.wav -b sideb.wav -o stitched.wav Same as overlap but, also stitches the 2 files together at the overlap if an overlap is found. Use -o to set an output filename. The default filename is "stitched.wav". The -f and -g option can be used to stitch files together without searching for an overlap but, both offsets must be supplied. ./maniacs.py -a sidea.wav -b sideb.wav -f 2188975 -g 293934 NOTE: The value used with side A via the -f switch is how many bytes to copy starting at the beginning of A. The value for the -g switch is how many bytes to skip at the beginning of side B. NOTE: If the source files are RIFF but the resulting file will be > 4GB, then the file will be saved as RF64. NOTE: Meta tags will be lost. NOTE: By default this requires a RIFF or a RF64 header for side A. Side B is blindly copied so side B can be any file type. Use --ignore_header to ignore the header in side A and blindly copy side A aswell. A sample of what the .json file looks like: Code: Select all { "comment": "side two; optical sp/dif; Pioneer DVL-v888; ICUSBAUDIO7D (C-Media Electronics, Inc. CM106 Like Sound Device)", "description": "10,000 Maniacs: MTV Unplugged (1994) [40183-6]", "hash_algorithm": "sha3_256", "ld_id": "08952", "payload_bytes": 339112672, "payload_hash": "553c1eb417e9698015aab1e53a3442a6ddb617496a2635e7db1190a7d045eb57", "sample_hash": "d594b228136f0ac470d14cee35bfc06254ca45fd1b39044ed4bd8bbcfb941a2a", "zzz_sample_base64": "xwA3/+0A3f4h/9P9Ef2A+xv8kfoP+4r7z/od/.....really long string" }

Author:	signofzeta [ 20 Jan 2023, 14:42 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
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…

Author:	teddanson [ 20 Jan 2023, 15:36 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
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

Author:	spiderfood [ 20 Jan 2023, 16:49 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
teddanson wrote: 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.

Author:	rein-o [ 20 Jan 2023, 17:00 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
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.

LaserDisc Database https://forum.lddb.com/

10,000 maniacs mtv unplugged audio bit perfect test https://forum.lddb.com/viewtopic.php?f=32&t=10733	Page 1 of 1

Author:	templar [ 20 Jan 2023, 17:28 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
Nice work! Check out Bit Perfect, similar concept but it checks each sample value of the audio.

Author:	spiderfood [ 20 Jan 2023, 18:45 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
templar wrote: 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. rein-o wrote: 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. 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.

Author:	templar [ 20 Jan 2023, 20:07 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
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!

Author:	spiderfood [ 20 Jan 2023, 21:44 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
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. Attachment: bitperfect_fail.jpg [ 36.49 KiB \| Viewed 3316 times ]

Author:	templar [ 20 Jan 2023, 21:58 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
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.

Author:	spiderfood [ 20 Jan 2023, 23:13 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
templar wrote: Hope that makes sense. 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). Attachment: stitch.gif [ 480.95 KiB \| Viewed 3307 times ] Here's a visual of creating a sampling... Attachment: create.gif [ 73.92 KiB \| Viewed 3307 times ] 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.

Author:	templar [ 21 Jan 2023, 00:07 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
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?

Author:	spiderfood [ 21 Jan 2023, 01:44 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
templar wrote: 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... spiderfood wrote: 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. 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.

Author:	templar [ 21 Jan 2023, 04:06 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
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.

Page 1 of 1	All times are UTC [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/

Author:	sonicboom [ 21 Jan 2023, 17:47 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
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 Quote: The actual choice of rate was the point of some debate, with other alternatives including 44.1 / 1.001 ≈ 44.056 kHz (corresponding to the NTSC color field rate of 60 / 1.001 = 59.94 Hz) 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.

Author:	spiderfood [ 21 Jan 2023, 19:52 ]
Post subject:	Re: 10,000 maniacs mtv unplugged audio bit perfect test
sonicboom wrote: 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. 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.