Lossless Audio Compression => Lossless / Other Codecs => Topic started by: Andrei_Vaughn on 2021-12-21 21:17:02

Title: Re-recording digital audio, best practices, multiple related questions
Post by: Andrei_Vaughn on 2021-12-21 21:17:02

I recently came across a situation, where someone ripped a reel-to-reel tape directly to a TEAC CD recorder, whilst this is impressive enough (real time recording to a CD!), I don't really care enough to verify if this is even what happened, it just seems like it...

My problem is with how this individual *potentially* converted said CD into an audio file, (WAV). I don't think they put the CD into their computer, but instead used RCA to 3.5mm audio adaptor, played it in the CD recorder, and recorded the output through a program such as audacity at 44/16, now, I had to think to myself, is this best practice? Is this a valid way to extract audio from a CD, or can it be problematic, and also is it better than using a CD reader attached to a PC, and then using a program such as EAC to extract the audio from the CD without having it be re-encoded to analogue and digital again? I would like to know if I should suggest to him to use a different method, but I have no mathematical or scientific basis to prove/disprove my concerns...

Following on from that question, I have one which is similar but not related. I would like to ask the same question, but this time pertaining to "screen recording", if there is a file in the format of 44.16 playing on my computer, through some program such as foobar which does not colour the output, it's playing on maximum system volume. If I were to record my PC's audio internally, in real time, (much like how people screen-record and have audio from videos, apps, games they're playing), and if I would record the same song digitally from start to finish in the same format of 44/16 (for example, something like OBS with a lossless audio output format), would there be any loss or degradation happening here?

If the second question is a tougher one to answer, I would ask that the first one is prioritised. If I do not get any answers for the second question, it may be possible for me to set up some kind of experiment, and do testing myself.

Thanks in advance to all the smart people that I just know are going to read this with either a perplexed expression or with a super eye-roll.
Title: Re: Re-recording digital audio, best practices, multiple related questions
Post by: j7n on 2021-12-21 21:41:56
The additional digital-analogue-digital step by playing and recording from a CD player introduces a little bit of noise and possibly AC hum from a ground loop or power cables in close proximity. The quality might be good enough, but if one has access to a computer, direct ripping is reliable and faster. If the CD player was connected with its S/PDIF output, then the stream might be captured perfectly. There is still a possibility that a buffer overflow might occur if the system is overloaded, or the sampling rate is not slaved to the input device resulting in a skip, which could only be detected by listening.

Whether you can capture the audio on your computer perfectly depends on the active sound subsystem and driver. Professional sound cards do usually feature a bit perfect routing and loopback from its digital and ASIO inputs. Sound coming from Windows Wave might be resampled, dithered or processed with a peak limiter. There again is a risk of a skip if the playback/recording is robbed of CPU time. Windows NT6 sound system is more sensitive to this than ASIO, or older NT5 kernel mixing.
Title: Re: Re-recording digital audio, best practices, multiple related questions
Post by: polemon on 2021-12-21 23:49:20
So, about the "screen recording" part:
If you're familiar with Jack or PulseAudio, all mixing is done internally, and each audio sink is accessible through a monitor output. This monitor output can be used as an audio stream for recording, and I've personally done so too, a couple times.
The bigger problem is things like delay when you're also recording video. Software to capture video and audio internally, usually has some means of adjusting the delay of either to get a perfectly synced AV recording or stream.

I'm not a Windows user, and I don't know if Jack is available for Windows (however I seem to remember that it is?), PulseAudio might be available for Windows, but I'm not sure at all.

When recording using a dedicated recording/streaming machine, audio and video from the main machine is usually fed into the recording machine via HDMI. Some content creators use a multi-camera setup and often an additional microphone, those are also fed into the recording/streaming machine. There is no analog step in between, however it essentially comes down to the power of the recording machine and things like bandwidth. Those things kinda come into consideration when you use very high-quality sources, such as a 4K/60fps main machine stream, plus each of the cameras, and of course you want good quality audio, too.

Now a little about digitizing reel-to-reel tape: Apparently it depends on just how much post-production you're willing to do.
The most "dedicated" setup I've seen, was someone taking apart most of a (decent quality, large hunk of a machine) reel-to-reel machine and designing their own amplifier and ADC they attached to the heads, circumventing all of the r2r's audio electronics. Also, they talked about controlling tape speed was like the biggest problem, since there's always gonna be some amount of wow and flutter, etc. They used a high-precision motor to drive the capstan, It was like from a video head, like a VCR or similar. Yet, they also had an optical tachometer at the flywheel of the capstan, and recorded the exact rotation of that to a very precise amount. They true'd the capstan in a lathe and etched a patter on on it. The optical pickup was an optical mouse sensor running at 12000fps which was apparently quite a lot at that time. This feedback was then later used to correct additional wow and flutter in software.
The reason they went to these lengths, because they had massive amounts of tape to digitize, he wouldn't say where the tapes came from, but it was apparently thousands if not tens of thousands of tapes. It was - as I understood it - for archival reasons, this wasn't part of someone's personal setup, instead it was made essentially to order. He was commissioned to digitize the tapes at the facility the tapes were kept in, so the instrument was essentially assembled at the site, and later more or less dismantled, as it wasn't really meant to be moved (I mean, a regular reel-to-reel machine isn't mobile either, but at least it survives transportation). This was at a maker-fare in 2016, iirc.

One thing I did ask about was the format he recorded into, he said it's RF64. This was also I think the first time I heard about RF64 I think. Interestingly, the signal from the wow-and-flutter meter was also recorded into the RF64 file as one of the channels. He also developed a bunch of tools for automatic correction of wow and flutter, and other aspects of the data, etc. All of it was in Matlab. He had his laptop with the software tools on there, the r2r was also controlled from the computer.

If I had lots of extra time in my life, it sounds like something I'd like to attempt at some point. The problem is rather, I have no tapes to digitize ┬ŽD