On Sunday, 4 January 2026 18:31:53 Greenwich Mean Time Alan Mackenzie wrote: > Hello, Michael. > > On Sun, Jan 04, 2026 at 12:30:37 +0000, Michael wrote:
> > In your process of elimination, did you also replace the DVD drive cable > > on the new PC? > > No, I didn't. That's one of the first things I should have tried. > However, I've tried it now, and the new cable doesn't make the fault go > away. :-( > > Is the audio CD crackling evident both on new (factory recorded) audio CDs > > and writeable CDs you burned yourself? If the latter, did you try more > > expensive disc brands and different (slower & then higher) burn speeds to > > see if the crackling goes away? > > I've only tried it on factory recorded CDs, so far. I think I've got a > bootleg one somewhere which I could look out and try. No point really, it should be able to play more reliably a manufactured recording to an audio CD production standard, rather than a home burn with potentially questionable burner parameters. > > Another trick which may work is to increase the cache size on the media > > player, e.g. 2x, 4x, 8x. It should give more time for the drive to > > perform > > its error correction gymnastics and hopefully overcome any media error. > > I tried increasing the "preferred buffer size" in deadbeef from 8192 to > 16384, without making any difference. Surely those figures are in > kilobytes, not bytes. I also tried increasing the "period size" > (whatever that is) from 1024 to 2048, independently of the buffer size. > That made no difference either. I was hoping this would resolve your problem. I tried playing an audio CD, while at the same time I ran hdparm -t on it to test its caching capability. It started crackling. As soon as the hdparm finished within a couple of seconds, the CD continued to play faultlessly. hdparm did not produce an output on audio CDs here, but it still tried to access the device. > > The crackling/reading problem at the start of CD/DVDs can happen because > > of > > light scatter from the transparent edge to the initial data tracks. I > > recall reading somewhere if you use a black marker pen at the back of the > > transparent region, you can fix this problem. The difference between old > > and new PC drives could be related to cheap-ification in components, > > lower energy laser, etc. > > I get the same ~6s crackle when moving the current position within a > track or starting listening at other than the first track, so I think it > unlikely that the transparent region is the problem. Whenever the head moves along the track to a new position, the reading/ caching/verification/error correction process starts again. Therefore I expect the same problem would manifest. I haven't used xine for decades now, because it had become temperamental at the time - but if it works then at least xine offers a workaround. Please post back if/when you crack this problem - I'd be interested to know how you fixed it. :-)
signature.asc
Description: This is a digitally signed message part.
