Drastic sound quality improvement: "Rewrite data" - audiophile software from Japan

[WindowsX]

That's where you get it wrong. Clock signal does involve in computer's digital audio. There're tons of professional sound card does support word clock signal. Even some Async USB devices where it does its own reclocking use high precision clock for better audio performance. Also, there's high precision event timer implemented for multimedia application in computer as well. You can't say it doesn't involve in computer audio from buffer to DAC. Some async USB digital audio interface devices feature high quality clock for superior signal. Even modern Esoteric's D-02/D-01 supporting async USB audio can gain improved performance with masterclock (22.579/24.576MHz) frequency from G-02/G-01.

 

[germanium]

  That's where you get it wrong. Clock signal does involve in computer's digital audio. There're tons of professional sound card does support word clock signal. Even some Async USB devices where it does its own reclocking use high precision clock for better audio performance. Also, there's high precision event timer implemented for multimedia application in computer as well. You can't say it doesn't involve in computer audio from buffer to DAC. Some async USB digital audio interface devices feature high quality clock for superior signal. Even modern Esoteric's D-02/D-01 supporting async USB audio can gain improved performance with masterclock (22.579/24.576MHz) frequency from G-02/G-01.

Of coarse when you are working with a DAW you are generally working with more than one soundcard & the clock signal must then be shared amongst all soundcards. DAW soundcards have that provision but not soundcards that are for consumer playback. What I have said holds true for consumer playback sound cards. In a DAW situation one needs to share a common clock in order to keep all cards in sync with each other. They still buffer the audio for playback of previously recorded material though to a smaller degree than consumer playback cards. Low  latency playback of currently being recorded material  most likely circumvents the buffering in order to achieve time alignment with the original though I'm not entirely sure on that aspect. I am sure about the rest however from a consumer play back perspective though. Sample data on playback of previously recorded material must be buffered due to the fact that computers do not provide a continuous data stream but data is delivered in spurts with no correlation to the playback sample rate other than not letting the buffer on the sound card go empty.

 

[WindowsX]

Esoteric D-02/D-01 has USB input for audio playback and I'm talking about that on customer's point of view using G-02/G-01 for computer audio.

 

[rb2013]

  I posted the captioned software to JPLAY forum at the end of December and would like to share it here as well.  The author is the same person who makes "Bug Head Emperor".
http://jplay.eu/forum/computer-audio/drastic-sound-quality-improvement-rewrite-data-1.0/
 
Download: http://1drv.ms/1nBAKyD
Rewrite data 1.19 (as of today) for Win7/8.1 64-bit
 
The program makes a bit-perfect copy of the original, checks the bit-perfectness, and overwrites the original, retaining its file properties.  If you open Explorer during the process, you see a temporary file whose name consists of digits.
The target files must be on a Win7/8.1 PC.  Applying to a network drive makes no sense.  Copying the processed files as well as moving them to a different drive loses the effect.
It is also effective to a USB memory and an SD card, which can be plugged out and be inserted into other pieces of equipment such as an SD card transport.
The effect vanishes gradually and the program should be applied again.
Please enjoy.

I've been using EAC (Exact Audio Copy) for years it's a pretty awesome program - but a bit daunting to set-up properly.  The program is designed to test the drive on your PC and calibrate itself and detect the Error Correction feature.  It reads each bit of a CD multiple times until it gets a repetitive match - it will keep reading that bit I believe up to 16 times before it gives up.  Once the image file is created it's checked against an online data base called AccurateRip.  I use the uncompressed Test & Copy Action mode.  I don't use the ID3 Taggging but prefer to use a Win Filename based tag - this usually created automatically from the Dbase online.
 
The idea is a spinning disc has to be read in realtime (less a slight buffer) and the player/transport has to rely on error correction frequently - producing a type of jitter.  Additionally the CD head itself is controlled by a servo motor that is notorious for creating jitter and feeding it back into the power supply - effecting the DAC's PS.
 
PS From the EAC website:

  In secure mode this program either reads every audio sector at least twice or rely on extended error information that some drives are able to return with the audio data. That is one reason why the program is slower than other rippers. But by using this technique non-identical sectors are detected. If an error occurs (read or sync error), the program keeps on reading this sector, until eight of 16 retries are identical, but at maximum one, three or five times (according to the selected error recovery quality) these 16 retries are read. So, in the worst case, bad sectors are read up to 82 times! But this effort will help the program to obtain the best result by comparing all of the retries.
If it is not sure that the audio stream is correct (at least that it can not be said at approx. 99.5%) the program will tell the user where the (possible) read error occurred. The program also tries to correct the jitter artefacts that occur on the first block of a track, so that each extraction should be exactly the same. On drives which have the “accurate stream” feature, this is guaranteed. Of course, this technology is a little bit more complex, especially with some CD drives which implements caching. When drives cache audio data, every sector read will be read from the drives cache and is that way always identical. Basically there are several ways to clear the cache. In newer versions it will overread sectors, so that the cache contains sectors from a position elsewhere on the CD.

 

[System54]

I've made a direct comparison, and it's unbelievable. I have done this with a command in the Ubuntu terminal.
The file (/mnt/sda1/Music.wav) will be copied into RAM; using {1..7} as an example, it will copy the file 7 times into RAM, but you can adjust the number.
The command is:

for i in {1..7}; do sudo cp -f /mnt/sda1/Music.wav /tmp; done

After that, I can play my music directly from /tmp.

 

[JotaroKujo]

I remember using some software called ReClock by Slysoft a very long time ago. It was originally made for video reclocking to smooth out video playback but also worked with audio only applications like Foobar2000, Lilith audio player et.al. Reclock did exactly what the name implies ie reclock data....it seemed to work to improve the sound in Foobar2000 back then....like 15 years ago. Seems this might be a sort of a rehash.

 

[Diet Kokaine]

the same happens with the "memory playback". I don't hear any improvement in the sound quality.

On my system. (2 channel speakers) Differences between memory playback are very audible.

On Jriver, memory playback without decoding has lower resolution and less sharp of a treble..
Memory playback that is decoded has the sharpest sound, where treble can become a bit piercing on some tracks.

No memory playback has the graniest sound, it sounds bad compared to the other options.
Sounds noisy.

Just my 2 cents.

 

[gregorio]

Reclock did exactly what the name implies ie reclock data....

Digital audio files don’t have any clock information and therefore cannot be re-clocked. They can be resampled and their pitch and speed altered, as is sometimes needed for pull-up/pull-down rates when changing film/video frame rates and maintaining audio sync, which is what that software was designed for. But that’s entirely different to what this software apparently claims, which is bit-perfect and therefore no re-sampling and no pitch and speed change.

On my system. (2 channel speakers) Differences between memory playback are very audible. ….
No memory playback has the graniest sound, it sounds bad compared to the other options.
Sounds noisy.

It’s not possible to playback digital audio files with “no memory”. In fact, there’s quite a few different memory locations digital audio playback has to pass through.

G

 

[Lohil]

I've built toy DACs from scratch and professionally real DACs from as close as one can to bear metal without an ASIC run (FPGAs)... this thread has got me scratching my head as to what people are talking about.... like in general anything audio would be encoded with is such low bandwidth and timing accuracy (from a digital hardware side) compared to modern digital transport layers that I'd be astonished if any of this jitter stuff is real (In terms of it mattering when the DAC gets it's bits). It's not like you just directly bit bang a DAC when you want it to make noise - it's always gonna have some kinda internal fifo buffer that will clock in and out bits at the same rate regardless of what feeds it as long as the fifo isn't depleted. The DAC's clock will have jitter but that'll be constant no matter what you do until you get a better DAC

But it has gotten me interested in what all this stuff could possible be

The software from the OG post has gotta be like a virus lol...
Even .flac is 1.4mbps unless you're reading random sectors from a 2.0 usb flash drive anything can sustain that... and again even if you couldn't it would buffer all over place and you'd still get the same audio output albeit with a little lag before the song started.

... realizing as I'm writing this this is a necro'ed thread

......

EAC though is interesting from a technical standpoint because it does appear to be real, in so far as people genuinely thought it was doing something, and yet I can't figure out why it would exist at any period of time.
Even if you were playing on a CD player in the 80s the reed-solomon would (should?) have been completely timing agnostic, that is to say the time it'd take to check and fix any errors (assuming they're fixable) should be exactly the same time it'd take to check and pass non error'ed bits as they'd literally come out on the same clock edge.

There's all this talk on the website about it's features but I just can't imagine what's it's doing... BER of an undamaged CD after FEC should be zero, so "rereading sectors" shouldn't do anything.
Attempting to find any sorta of paper on this, there is this https://www.tandfonline.com/doi/full/10.1080/15567280701418098#d1e2321
But this is really for cases of a difference in writing with TAO vs DAO but these are completely different from an electro stamped method to mass produce CDs...

Perhaps this was all for dealing with damaged CDs? But then again once you've exceeded your FEC's error tolerance, some amount of data is gone, and no amount of re-reads will bring it back.. unless there's a probability associated with reading a damaged sector haha oh man what a rabbit hole

 

[VNandor]

EAC though is interesting from a technical standpoint because it does appear to be real, in so far as people genuinely thought it was doing something, and yet I can't figure out why it would exist at any period of time.

It does "something" but it does not claim to magically improve sound quality while creating a bit perfect copy.
Here is a list of what EAC does: https://www.exactaudiocopy.de/en/index.php/overview/features/features-of-eac/
If these features were not present in other CD ripping softwares back in the day, I think it's understandable why it got popular.

 

[gregorio]

EAC though is interesting from a technical standpoint because it does appear to be real, in so far as people genuinely thought it was doing something, and yet I can't figure out why it would exist at any period of time.

It would exist in the period of time when CD ROM drives and recordable CDs became widespread in personal computers in the 1990’s. Unlike an Audio CD that are compliant with RedBook specs and therefore contains Reed-Solomon error correction, that was not necessarily the case with data CDs, which were defined by the YellowBook specs. Digging deep into my memory (which could therefore easily be wrong!), YellowBook allowed for two “Modes”, mode 1 and mode 2. Mode 1 contained all the error detection and correction code of the RedBook specs but Mode 2 did not, it allowed more space for user data by not including the error detection and correction code but of course was more prone to uncorrected read errors.

So there could have been some practical benefit of EAC when ripping audio from data CDs. There was also an OrangeBook for CD-RW incidentally but I don’t recall what modes or error correction it allowed for.

G

 

[Lohil]

It would exist in the period of time when CD ROM drives and recordable CDs became widespread in personal computers in the 1990’s. Unlike an Audio CD that are compliant with RedBook specs and therefore contains Reed-Solomon error correction, that was not necessarily the case with data CDs, which were defined by the YellowBook specs. Digging deep into my memory (which could therefore easily be wrong!), YellowBook allowed for two “Modes”, mode 1 and mode 2. Mode 1 contained all the error detection and correction code of the RedBook specs but Mode 2 did not, it allowed more space for user data by not including the error detection and correction code but of course was more prone to uncorrected read errors.

So there could have been some practical benefit of EAC when ripping audio from data CDs. There was also an OrangeBook for CD-RW incidentally but I don’t recall what modes or error correction it allowed for.

G

Ohhh interesting yeah looking it up here https://www.mediatechnics.com/yellowbook.htm you'd be right mode2 on yellow book didn't support as much error correction. I suppose then more for pirates of the 90s?

 

[gregorio]

I suppose then more for pirates of the 90s?

Yep, or if there were any CD data drives that didn’t use the RedBook R/S code to error correct the data it read (I don’t know if there were any such drives) or if there were any officially released audio recordings that exceeded the redbook duration or contained other data and therefore used YellowBook Mode 2.

G