 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
76.79.86.51
In Reply to: RE: How small can a tweak be and still affect the sound? Nt posted by johndyson10 on July 06, 2023 at 18:03:08
I assume this project is not a consumer HiFi application?
My project is a research project, source/binary free. It undoes what was originally called 'digital sound' back in the 1980's. Many attempts of micro-improvements probably come from the unreal sound of most consumer recordigns.
The program is crazy complex and crazy high-tech... It can use up to about 80 threads, and on my 10 core machine runs barely faster than realtime. It does a lot of high tech processing. Some techniques never existed before, necessary to remove the 'sidebands' created by the massive gain control during the creation (distortion) of the consumer digital copy. The decoder can also remove the distortion sidebands (Fog) created on old recordings when DolbyA and Telcom NR systems were used.
(Yes, the 'distortion' technique was originally analog and is also used on a lot of analog vinyl. Also, alot of recordings, e.g. Telarc stuff is also distorted.)
The next, much better release is coming soon.
It IS possible to use the program in realtime as a HiFi application, I certainly do when testing/verification. However, it is best to clean up your library ONCE, and usee the very slow, highest quality modes that do the maximum recovery.
It is not a play toy, but does reveal what the original recording sounds like. It is NOT a consumer tweak, and once released mostly requires no tweaks by the consumer. Just don't use any gain between your original recording source and the decoding program. Levels are critical.
John Dyson
PS: the development is probably 5yrs before an actual product would be possible. Once product comes out, perhaps 95% of the defects in recordings will be corrected. Of course, there will always be the f-ed up recordings for which nothing can be done.
This is something GOOD, profoundly good. Right now, it might be a little too much for those not used to PCs or Linux machines, but once it is packed into a pretty product that makes the user 'feel real good', then the full improvement will be realized.
The decoder project ONLY does the physical, technical correction. It takes the marketing types to put it in a pretty box or software package for emotional and better perceptual appeal...
John Dyson
Does it process digital audio in real time with a sound card installed? Or is it file based only where it processes off line and creates a new processed file for playback?
The 'corrector' or 'decoder' works on the digital file.You can also directly play realtime in a system it knows how to interface to, but primarily intended to convert a recording, either in album, track or entire set of directories. Most of the time, for convienence, I use SoX for the file conversions/etc, so it does some nice things making using the decoder a little nicer -- but does add it's own flaws also. For the larger scale operation, a shell script of some kind is currently needed... Some day, there will be a GUI that makes some of the automation easier for people who use computers differently than an engineer or comp-sci person might.
Natively, it only works with .wav files, and prefers 44.1kHz/48k input, but is perfectly happy with any other reasonable standard or nonstandard rate. It accepts 16bit, 24bit and FP inputs.
Output rate is 88.2k for 44.1k inputs, and 96k for 48k inputs -- there is a method to that madness. For input rates above and equal 88.2kHz, the output rate will be the same. For those who like to waste disk space (humor intended), it also supports 352.8kHz/384kHz input/output,
It prefers to output in FP form, but can also do 24bit just as well. 16bit is explicitly not supported for output, in the past it used to be. Since the decoder sort-of adds pseudo-accurate lower 'bits' to the output, it seemed like the 16bit mess for output isn't worth the trouble.
The decoder maintains & modifies when appropriate, most normal metadata along with supporting BEXT metadata, and also supports RF64 for working on full albums, needed especially for FP.
If interested, I'll bring this back up again when something is good enough to demo outside of those who expect imperfection from time to time.
I don't want anyone else to be disappointed by one of my f-ups, so will delay 'bringing this up again' until it is ready for plausibly BETA use.
Just tell me, and I'll support in any way that I can.I don't do the $$$ thing, because that is for people who use the technology and produce a good product form. The project got started to solve a problem, and ended up with a damned good DolbyA decoder along the way also.
Have fun!!! I certainly am...
John Dyson
Edits: 07/07/23
Sounds very cool. Keep us posted on your milestones.As for using SoX, you might want to switch to FFMPEG. SoX hasn't been touched/maintained in years. FFMPEG is actively maintained.
SoX is also 32-bit internally where FFMPEG is 64-bit internally. If you use SoX to transcode 64-bit content (e.g. WAV2PCM and PCM2WAV), SoX nukes the 64-bit content.
I have been updating DRC-FIR to work at the driver level, work in 128-bit quad float internally and use FFMPEG for transcoding to get around SoX's 32-bit internal limit (as well as eliminate manual pilot errors). Also added 128-bit FFTW which is actively maintained.
.
2022/03/30 Historical Records CENSORED
Edits: 07/07/23 07/07/23
z
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2025, Audio Asylum, all rights reserved ]
