Secure (Recover Errors) mode results in choppy audio

[artisan002]

So, this is post is more about technical insight to the problem than anything else. Using Burst mode gets perfectly fine results for what I'm doing, but I am intensely curious to know what this is all about.

I am on my 5th attempt to archive my collection (several long stories at this point). I'm currently ripping some Depeche Mode CDs that were reissued in 1991. Matrix/runout codes for the first two are "1 40291-2 SRC**03 M1S2" and "1 40292-2 SRC**03 M1S1", respectively — just in case that helps. My Asus SDRW-08U9M-U has issues with them even in burst mode, but consistently would mark the 2nd track in both CDs as insecure and inaccurate. Ripping the 2nd tracks as a defective disc would resolve the issue; I no longer remember if Burst mode for these tracks errored out or not. It's acted up a few times since I bought it; so I opted to replace it with a Mercury Pro by OWC (in dBpoweramp, it identifies itself as "HL-DT-ST -BD-RE BH16NS40"). Initially, CD Ripper (current version) wouldn't allow to test for new offset with the new drive, specifically when using one of these two aforementioned CDs; I had to use an unrelated CD from 1990 to get it to register the correct +6. Both before and after I solved this, however, the new drive would rip in Secure (Recover Errors) mode with square wave style dropouts. Seriously, it sounded like some kid wanted to become a trance DJ and dropped a double-timed gate effect on the whole song. Switching to Burst mode, however, everything with these odd discs goes fine. They have precious few light scratches on them, and they'll play in real-time with zero issues.

I'm fairly certain that it's a problem specific with these reissues, and therefore assume it's just some funky DRM; but I definitely don't know for sure. It's all just very curious, and I'm wondering if anyone has any insight as to what's going on here. Similarly, I have two completely different CDs that rip as if they had a low-pass filter applied to them, but play in full frequency range. I have failed to learn anything concrete about any of this via the internet, but also don't really have a good sense of what to include in my search strings.

To reiterate, I'm not in a real problem spot, here. But, I love learning the technicals behind this kind of stuff. So, yeah. If anyone has technical insight on this matter, I'd love to hear about it.

[Spoon]

Re: Secure (Recover Errors) mode results in choppy audio

Ensure c2 error pointers is off, for some drives this causes issues, also check the DSP effects and disable the pre-emphasis and HDCD if have them as already mentioned.

[artisan002]

Re: Secure (Recover Errors) mode results in choppy audio

Okay, that is just weird to me. I wouldn't have thought pre-emphasis would have created a low pass filter type of effect, as opposed to just making everything play quiet. Huh..! And I see that "Apply De-emphasis to CD tracks marked with Pre-emphasis" is already checked by default, just like it's been for years. So, I guess I should be undoing that, then. Hell, I may re-rip everything I just completed, as a precaution. Humorously, I just added HDCD DSP to the mix, since I know I have a couple such discs in my collection that I'll be archiving soon.

As for the other curiosities I detailed, I found that &*8212; despite the new drive running on USB 3.1 &*8212; selecting "8KB Transfers (C2 pointers over USB / Firewire)" solves the curious gate-like problem, though only for that one drive. Considering the data throughput of USB 3, I just assumed it was a pseudo-legacy inclusion and wouldn't matter; clearly I have learned otherwise. LOL! The Asus drive is USB 2.x, and wasn't helped by that feature being active or not. But, having seen you explain the C2 pointers thing before, I knew not to rely on it with that drive anyway; it also didn't always identify itself as supporting C2 Pointers, but I grew to just accept that that particular drive was just odd. This whole field is so unbelievably niche. I so damned glad you or anyone somehow understands it enough to answer such seemingly bizarre stuff.

Thanks, as always.
(I really feel like there's more to discuss and learn, here, too. But, I've no clue what that would be, nor do I feel like dragging people through taking me by the hand over stuff like this. LOL)


UPDATE: It seems I have a follow-on question after all. I'm going to go research it myself, of course; but, I also need to sort out a control methodology. I just re-ripped the LFO's 1991 speaker busting classic "We Are Back / LFO". Then, I read responses here and re-ripped it again (as a 24 bit 96 kHz .wav; the only difference versus normal rips being wave format as opposed to FLAC). The result was quite pronounced. Much more high frequency information (bordering on harsh, in fact), and what sounds like distortion on bassy passages of the opening track (not even the heavy song). I'm fairly certain it's baked into the master, but need to verify. While I'm losing myself in that, does anyone have input on the matter? 'Cause this is very intriguing to me.

[Dat Ei]

Re: Secure (Recover Errors) mode results in choppy audio

To get you right: you have ripped an Audio CD (redbook) with 24 bit 96 kHz?


Dat Ei

[artisan002]

Re: Secure (Recover Errors) mode results in choppy audio

Correct. My apologies for a shortage of details. I ended up trying to solve a couple things going wrong in the house, and didn't get to finish clarifying before the edit timer ran out.

To clarify, in all of my rips, I'm resampling to 96 kHz, 24 bit then saving to the same thing. I do have a somewhat valid reason for this. However, I also know there will always be that one overly sensitive individual in every audio community who has scratched the surface of some science and paints his profuse opinions with it, hoping to seem like he has greater wisdom. I have zero interest in that particular debate, just in case that was a planned angle of debate. I've also used this methodology for nearly 10 years now. I understand it well enough to be comfortable in it.

Now, in all this time I've never had occasion to test the pre-emphasis settings before. De-emphasis is selected by default, and I've been perfectly willing to trust Spoon's wisdom on that. So, these results I've found are new and fascinating to me. Clearly I need to learn a fair bit more about pre-emphasis. Also, I'd do well to find a CD that I can trust was more expertly engineered at the studio level. But, I was truly surprised by the difference in just shutting off de-emphasis.

[Dat Ei]

Re: Secure (Recover Errors) mode results in choppy audio

But ripping and resampling an Audio CD (redbook) to 24bit and 96kHz does not make any sense at all. An Audio CD has a sample rate of 16bit and 44,1kHz, which can encode a frequency of max. 22,05kHz (nyquist shannon theorem). So higher sample rates increase the data volume but not the sound quality or range of frequencies.

Dat Ei

[artisan002]

Re: Secure (Recover Errors) mode results in choppy audio

Barcode/UPC is: 0 16998-0994-2 1

You're better of using Matrix/Runout codes for greater specificity. Said codes on this disc are: ARC 43 TBCD 994-2 SRC=01. Discogs can only identify it if you drop the ARC and SRC bits. But, you may have another resource to use that I lack access to or awareness of.

So, at this point, the mix engineer in me is finding it all fascinating. I just don't quite get the point to pre-emphasis, though. If you want your audio to run at a certain level of loud, then just make it that way. Unless, maybe it's a foil for dreaded DC offset? I just don't know, which is part of the point. But, I've not had a strong reason to look into it much in the past, and what little I did find wasn't really enlightening. It's also been a while, and the Internet shuffles links in and out enough that I should look again. But, my brain just wonders, now. Is the de-emphasized output how it was intended to sound? Or, was that more of a move to ensure equal quality playback on more devices, etc.?

And, again, I don't really think turning de-emphasis off introduced distortion. But, it definitely changed the sound from what I'm used to. I'm not certain if the dynamics changed that much, or if the tone just changed enough to feel like that. I know for sure that there is noticeably more high frequency content than before. In this particular case, there's a lot more going on between 3kHz and about 7kHz, and not in a good way. But, that's already so often an accidental problem in recording that there are companies who make multi-band compressors the 2nd compressor is tuned just for that band. So, that may just be the issue. All the more to the point that I need to take time to find a more reliable comparison album as a kind of control.

[artisan002]

Re: Secure (Recover Errors) mode results in choppy audio

Dat Ei... Seriously. What did I say about this? You read that part, yes? I specifically wanted to avoid this right here. But, you did it anyway. This robs the thread of it's point, with little more than opinion wagging. And you've clearly never tried it and compared your results in a spectrogram. Furthermore, I did note that it was resampling in the process.

[GBrown]

Re: Secure (Recover Errors) mode results in choppy audio

Dat Ei... Seriously. What did I say about this? You read that part, yes? I specifically wanted to avoid this right here. But, you did it anyway. This robs the thread of it's point, with little more than opinion wagging. And you've clearly never tried it and compared your results in a spectrogram. Furthermore, I did note that it was resampling in the process.

To each their own. But you can't make something out of nothing. The Redbook CD standard effectively is it's own "compression" format, sampling true analog into samples of 16 bit depth and at a rate 44.1kHz. There is no existing data in between these samples. Up-converting to 96kHz will double the number of slices, but this is just duplication. Increasing the bit depth doesn't add any value either. What does happen is larger file sizes that result in the exact same level of digital detail. But if you perceive this to be different, have at it. Storage is pretty cheap these days.

[mville]

Re: Secure (Recover Errors) mode results in choppy audio

Dat Ei... Seriously. What did I say about this? You read that part, yes? I specifically wanted to avoid this right here. But, you did it anyway. This robs the thread of it's point, with little more than opinion wagging.

Dat Ei is NOT stating an opinion, but a fact.

Just to clarify for other users who may be reading this thread, ripping a redbook audio CD to 24-bit, 96kHz will NOT improve the sound quality.

If the OP believes that it does , that is their prerogative.

[artisan002]

Re: Secure (Recover Errors) mode results in choppy audio

And, thus the thread is broken. Good job, kids! You missed the point because you're sure a glossy overview of some math means results are absolute. I imagine the lot of you also think every DAW and music player in production puts out identical sound.

And let's remember that this objection is barely relevant to the subject and definitely doesn't have any effect on it &*8212; which makes said objection both pointless and disrespectful to the topic, and drives it all into the same ignorant ditch it always does in here. It's just such trope level, low mental effort outrage.
Some poltroon thinks there's a point to doing something I disagree with!?! Even though he hasn't explained his reasoning? Ha! I certainly know better, if I do say so myself. Clearly, he's a fool who doesn't understand math, or what adherence to a topic actually looks like.

Well, the thread survived about as long as every other one I see in here that dares to do anything that runs counter to superficial understandings of DSP. Not even the issue at hand, but that extra-sensitive few of you who like to type too much sure did save the day for yourselves. LOL!

[Spoon]

Re: Secure (Recover Errors) mode results in choppy audio

Well, the thread survived about as long as every other one I see in here that dares to do anything that runs counter to superficial understandings of DSP.

For the record we have never removed any posts on forum.dbpoweramp.com relating to peoples perception of sound. Not once in the 21 years this forum has operate.

[artisan002]

Re: Secure (Recover Errors) mode results in choppy audio

For the record we have never removed any posts on forum.dbpoweramp.com relating to peoples perception of sound. Not once in the 21 years this forum has operate.

Heh. I never said anyone was deleting threads, nor had I even thought about that. I strictly meant this thread is functionally dead, because it's been pulled off topic by the very phenomenon I didn't want to see happen. I suppose someone could force it back on target. But, it hasn't really happened with other threads I've seen take this same turn.

[GBrown]

Re: Secure (Recover Errors) mode results in choppy audio

Heh. I never said anyone was deleting threads, nor had I even thought about that. I strictly meant this thread is functionally dead, because it's been pulled off topic by the very phenomenon I didn't want to see happen. I suppose someone could force it back on target. But, it hasn't really happened with other threads I've seen take this same turn.

So getting back on track then, in post *4 below it looks like the issues were resolved in this case by making a change to the drive conditions regarding C2 error pointers. Seems at least one of the drives in use reported that this was supported, but in fact we&*8217;re not. This has been noted in the past, but keep in mind these drives are being optimized for data use, not for us 0.1% audio users.

The benefit of using dbPoweramp in this case is pretty big. Almost all other programs that provide the ability to rip audio CDs simply do not offer these background options for correction. They just rip what they can and don&*8217;t report much other than "Done" when they finish.

[artisan002]

Re: Secure (Recover Errors) mode results in choppy audio

Heh. Yeah. That has been sorted for the most part. And, equally agreed about the myriad drives and their purposes. The Asus one was a purchase under pressure. I trusted a friend (who routinely asserts he knows more about tech) who managed to wreck a $1000+ computer rig, my entire music archive, 6+ years of personal music work (backup drive was in a SATA dock at the time of disaster), and a brand new Pioneer BDR-209DBK. Trust is thoroughly broken now. But, yeah. I'm finally back to sorting my collection and ran into a few quirks. I had hoped the Asus drive would do the job, and it definitely does not. It was $35, so I held out hope more than actually expected great things. And, very little of that is actually surprising to me, just considering the range of prices and capabilities of so many drives that are out there. The legit surprise for me was the fact that the 8KB setting for USB would still apply to a drive running USB 3.1. LOL! Now, when I think about it more, then I know I should have immediately been suspicious about that. After all, just because it's has a USB 3.1 connection does not mean it's using USB 3.1 protocols. There's not even a point to it, given that we can stream a CD on USB 1. It's just somewhat futureproofed this way. In the end, it's just one more case of me trying to do too many things at once with not enough time, and thus not thinking through that last hurdle of logic.

Now, the new point of fascination for me is exactly what pre-emphasis/de-emphasis is doing. I had thought I understood the basic concept. What little I've found indicates that pre-emphasis is a loudness control. I get that. It makes a certain sense, though I don't understand why it's there, which would be legitimately cool to know about. But, in playing with it, I'm very surprised to find that it doesn't seem to be a "broadband" application of loudness/attenuation applied evenly across the entire spectrum. And that makes this even more fascinating to me. But, since I'm still dealing with a lot at once, I've not yet come back around with other samples to reference against. So, it might be as simple and straightforward as I thought. But, that raises new questions because of the one result I've experienced so far. But, I'm also very conscious that it's just the one result so far.

So, anyway, that's where I'm at in all this. I'd love to know more. Because, clearly, what little I've managed to find about it in the past has failed to be helpful.