Izotope SRC

[bdiament]

Hi Alex,

 

Sorry Barry, I am not following you here. If you upsample/oversample/interpolate/whatever at all, then you have a filter with coefficients and the original data is altered. Do it in software, do it in a DAC's separate DF chip, do it in the DAC chip's built-in filters as part of the delta-sigma modulation--it's all an alteration, and the choice comes down to the parameters and sonic results/trade-offs of each. Am I missing something? (very likely, so feel free to correct/enlighten me)

 

I wish I knew how to be more clear about this. I had a discussion about it recently with the designer of the converters I use. (He is one of the very few folks I've been fortunate enough to have met and spoken with, who I believe is a genuine genius. Half an hour conversation with him feels like I graduated with honors from a 3-credit class. ;-})

 

What follows is my "understanding" of what he told me in response to my question about whether upsampling in DAC filters is the same as upward sample rate conversion. Those parts of what follow which are correct, belong to the designer. If any errors follow, they are mine alone.

 

He said the answer to my question is somewhere between yes and no and that it depends on which point one considers the audio stream to transition from data to analog conversion.

 

If I understood him properly, the PCM stream that enters an oversampling converter (at least *his* design but I would think others too) is the same as what is being played from the DAW (or software player).

 

Again, if I understood him correctly, he was saysing a sigma-delta DAC is in a way a hybrid of digital and analog technology and that it is really an analog process with a digital feedback loop of sorts. The converter generates a very high frequency square wave that is pulse width modulated with a feedback path - the width of the pulses is set by whether the voltage of the output is higher or lower than the desired voltage. (Something like a Class D amp.)

Apparently, this can all be done in the analog domain but there are improvements possible with feedback in the digital domain.

 

He told me it is very difficult to get good performance from a single-bit modulator, so he uses multibit DACs, which means there is some sort of synchronous SRC from 24-bit at the source sample rate Fs to 8Fs, so, internally, when running 192k into the converter, the multibit modulator is running at 1.536 MHz.

The type of SRC done within the interpolator/modulator is completely synchronous, so it works much like offline SRC. He told me on-the-fly SRC is generally asynchronous, so it does rate and ratio estimation. Variation in that estimate causes low-level time and frequency dependent distortion that he tells me is likely the source of the brightening and hardening I hear in comparison to off-line SRC -- if it is done well (!) -- and worse if not done well.

 

According to him, synchronous SRC can be made essentially perfect, depending on how many resources one is willing to devote to it. Properly implemented, it is essentially the same as simply digitizing at a different sample rate. When upsampling, new (redundant) data is interpolated. If the upsampling rate is an integer (as with the DACs he uses), the original data stream remains embedded and untouched in the upsampled stream. In fact, you can drop the new interpolated samples from the stream without any additional filtering and still have a valid stream at the lower sample rate. So why do it? He says it is easier and cheaper to make really good digital filters than it is to make really good analog filters. By moving the analog domain antialiasing filters to frequencies much higher than the highest frequency present in the stream, you can use a much lower order, cheaper, less steep filter to anti-image the analog signal into a proper bandlimited signal at the output of the converter block, for better results with less power and less noise.

 

At the very least, this explains (to me) why I've never responded to oversampling in a converter in the same (negative) way I respond to real-time sample rate conversion using even the most transparent SRC algorithm in my experience.

 

I hope I did justice to what he told me.

 

Best regards,

Barry

Soundkeeper Recordings

The Soundkeeper | Audio, Music, Recording, Playback

Barry Diament Audio

[Miska]

If I understood him properly, the PCM stream that enters an oversampling converter (at least *his* design but I would think others too) is the same as what is being played from the DAW (or software player).

 

Only in case it wasn't processed on the way...

 

Again, if I understood him correctly, he was saysing a sigma-delta DAC is in a way a hybrid of digital and analog technology and that it is really an analog process with a digital feedback loop of sorts. The converter generates a very high frequency square wave that is pulse width modulated with a feedback path - the width of the pulses is set by whether the voltage of the output is higher or lower than the desired voltage.

 

No, the delta-sigma modulation process is entirely digital (DSP operation).

 

Apparently, this can all be done in the analog domain but there are improvements possible with feedback in the digital domain.

 

No, this is only the case with ADC side...

 

He told me it is very difficult to get good performance from a single-bit modulator, so he uses multibit DACs, which means there is some sort of synchronous SRC from 24-bit at the source sample rate Fs to 8Fs, so, internally, when running 192k into the converter, the multibit modulator is running at 1.536 MHz.

 

Wrong, the synchronous SRC performs operation to 8fs which is using the 1x rate (44.1/48) used as reference. So the target rate is 352.8/384 kHz and thus 44.1/48 is multiplied by 8, 88.2/96 by 4 and 176.4/192 by 2.

 

This is also very apparent from spectrum analysis results from DAC outputs.

 

This "8fs" rate is quite low, but the DAC chips don't have enough master clock cycles per input sample to do better. While the delta-sigma modulator needs to operate at higher frequency, typically 5.6/6.1 MHz (same as DSD128). So in order to achieve this higher rate from the 8fs rate without DSP resources, sample-and-hold type "interpolation" by factor of 16x is used. This is just simply copying the same sample 16 times in row.

 

The type of SRC done within the interpolator/modulator is completely synchronous, so it works much like offline SRC. He told me on-the-fly SRC is generally asynchronous, so it does rate and ratio estimation.

 

Now, HQPlayer has 14 up-sampling filters of which just one is asynchronous. All 13 others are synchronous. All the six oversampling filters offered for delta-sigma modulated output are also synchronous (target rate 64fs - 512fs).

 

All performed on-the-fly.

 

Variation in that estimate causes low-level time and frequency dependent distortion that he tells me is likely the source of the brightening and hardening I hear in comparison to off-line SRC -- if it is done well (!) -- and worse if not done well.

 

That's the case with ASRC, but nobody was specifically speaking of ASRC here?

 

According to him, synchronous SRC can be made essentially perfect, depending on how many resources one is willing to devote to it. Properly implemented, it is essentially the same as simply digitizing at a different sample rate. When upsampling, new (redundant) data is interpolated. If the upsampling rate is an integer (as with the DACs he uses), the original data stream remains embedded and untouched in the upsampled stream.

 

The funny part is that conversion from 44.1k to 192k can be A) synchronous, B) integer and C) all the samples are still completely new. While also conversion from 44.1k to 176.4k can also be synchronous, integer and still all the samples may be completely new. Only with certain restrictions the every Nth sample can be same as the source one, but there are still for example 75% of new samples and 25% original.

 

In fact, you can drop the new interpolated samples from the stream without any additional filtering and still have a valid stream at the lower sample rate.

 

Yes, HQPlayer also has couple of such filters, but this doesn't mean anything in practice, because the delta-sigma modulator will come and create entirely different kind of samples anyway before it reaches conversion stage.

 

At the very least, this explains (to me) why I've never responded to oversampling in a converter in the same (negative) way I respond to real-time sample rate conversion using even the most transparent SRC algorithm in my experience.

 

I can implement exactly same oversampling filters in software that are implemented in DAC chip, so the point is moot.

[bdiament]

Hi Miska,

 

Looking over some of the communications I received from him, I believe I told it the way he told it to me. In view of that, forgive me if I choose to take his word for it.

 

Best regards,

Barry

Soundkeeper Recordings

The Soundkeeper | Audio, Music, Recording, Playback

Barry Diament Audio

[Miska]

Looking over some of the communications I received from him, I believe I told it the way he told it to me. In view of that, forgive me if I choose to take his word for it.

 

I don't mind.

 

DAC's are easy to study and manufacturers publish quite good information on theory of operation. I'll also keep posting more measurement results over time (for example the 8fs thing is quite apparent from the results when you see aliases around every 352.8/384).

 

For hardware, I've done quite a bunch of studying over the past about 25 years. For software I can only speak of my own algorithms, designed and implemented by me personally.

[Jud]

 

That's the case with ASRC, but nobody was specifically speaking of ASRC.

 

The way Barry's explanation reads, that appears to be exactly what the Metric Halo's designer was doing, comparing the MH to an ASRC DAC (like the Benchmarks).

[Miska]

The way Barry's explanation reads, that appears to be exactly what the Metric Halo's designer was doing, comparing the MH to an ASRC DAC (like the Benchmarks).

 

That I understand, but I feel that it's out of context here. Or did I fall out of discussion context somewhere? (entirely possible too)

 

Upsampling/oversampling/interpolation/etc is not as such related to ASRC. But ASRCs are usually used primarily to fight jitter and not alone just to change the sampling rate.

 

When there's an ASRC in the chain, like is case with certain DACs (like many from Musical Fidelity and many Sabre based), it is usually good from performance point of view to feed these with the constant rate they actually use for output. So the converter does just 1:1 conversion with minor adjustments to reduce jitter. Less there is jitter on input of this 1:1 conversion, less modification to the original data is performed...

 

In these kind of cases it also makes sense to upsample before the device, so the alterations there are reduced.

 

For example many AVR's run internally at static 192 kHz sampling rate, because all the DRC and X-over is designed only for that rate (that is also commonly used on BD). And the internal ASRCs or SSRCs performing input conversion to that rate are less than ideal, so better catch the 1:1 case.

[Jud]

That I understand, but I feel that it's out of context here. Or did I fall out of discussion context somewhere? (entirely possible too)

 

Upsampling/oversampling/interpolation/etc is not as such related to ASRC. But ASRCs are usually used primarily to fight jitter and not alone just to change the sampling rate.

 

When there's an ASRC in the chain, like is case with certain DACs (like many from Musical Fidelity and many Sabre based), it is usually good from performance point of view to feed these with the constant rate they actually use for output. So the converter does just 1:1 conversion with minor adjustments to reduce jitter. Less there is jitter on input of this 1:1 conversion, less modification to the original data is performed...

 

In these kind of cases it also makes sense to upsample before the device, so the alterations there are reduced.

 

For example many AVR's run internally at static 192 kHz sampling rate, because all the DRC and X-over is designed only for that rate (that is also commonly used on BD). And the internal ASRCs or SSRCs performing input conversion to that rate are less than ideal, so better catch the 1:1 case.

 

Yeah, I mentioned ASRC just to give some context and very general understanding around what Barry had said. It also helps explain what Boris is hearing, since his Benchmark will do its ASRC (to 110kHz?) regardless of whether software SRC takes place upstream.

[Superdad]

Big thank yous to both Miska and Barry. Excellent discussion and explanations.

 

My poor old brain is still somewhat wired to think of things mostly in R2R ladder DAC terms so I am working hard lately to wrap my head around all the permutations of D-S modulators (and how they can also be multi-bit and multi-level, as well as use other coding scheme math)! A fascinating area, especially since there are some functions which really lend themselves to s/w (due to ample computer resources), while others are best done in hardware.

 

I realize the above has little to do with sample rate conversion, but the interesting work Miska is doing with HQPlayer is making my mind dwell on the various aspects of busting apart the functions built into commodity DAC chips.

 

I am still not entirely clear on what means Miksa uses to send a DSD256 rate data stream (created by s/w DSM of PCM files) to a DAC, and via what interface. I do see that the exaSound e20 takes DSD256, but only when using their own special Windows ASIO driver. Is that via USB or does it require an S/PDIF output card from the computer? Obviously when using their own driver and DAC DoP is not required. What driver does HQPlayer use when sending out a high-rate DSD stream?

And is an ESS-based DAC really the best place to send such a potentially artifact-free stream? It likely could be better served by a simpler architecture for the silicon side of the process.

Sorry to stray so far off topic.

[Miska]

Yeah, I mentioned ASRC just to give some context and very general understanding around what Barry had said. It also helps explain what Boris is hearing, since his Benchmark will do its ASRC (to 110kHz?) regardless of whether software SRC takes place upstream.

 

Ahh, that's the part I somehow missed! The older Benchmark DAC1 had such SRC (was it ASRC or SSRC?), but I have not found exact information on what the DAC2 does. DSD would probably bypass it...

[Miska]

I am still not entirely clear on what means Miksa uses to send a DSD256 rate data stream (created by s/w DSM of PCM files) to a DAC, and via what interface. I do see that the exaSound e20 takes DSD256, but only when using their own special Windows ASIO driver. Is that via USB or does it require an S/PDIF output card from the computer? Obviously when using their own driver and DAC DoP is not required. What driver does HQPlayer use when sending out a high-rate DSD stream?

 

We are getting pretty OT for this thread now...

 

Currently it practically means ASIO driver on Windows, no DoP. Either exaSound or some Amanero-based device. I just have the Amanero board for my own experiments (work-in-progress). On Windows I always prefer a native ASIO driver when such is available.

 

Another option is to use the fresh native DSD support in Linux, but this is another work-in-progress item.

 

And is an ESS-based DAC really the best place to send such a potentially artifact-free stream? It likely could be better served by a simpler architecture for the silicon side of the process.

 

For some quick-and-dirty testing purposes I was planning to combine PCM1792A configured to static DSD mode with the Amanero board. Until I get to better state with the discrete DAC experiments @DSD64/DSD128.

 

Edit: And one alternative was Antelope Zodiac Platinum.

[Jud]

Ahh, that's the part I somehow missed! The older Benchmark DAC1 had such SRC (was it ASRC or SSRC?), but I have not found exact information on what the DAC2 does. DSD would probably bypass it...

 

DSD wouldn't use iZotope's upsampling either.

 

I thought I read some marketing stuff on Benchmark's site that sounded like they used both async USB input and ASRC in the DAC2, but I am not certain.

[bdiament]

Hi Miska,

 

I don't mind.

 

DAC's are easy to study and manufacturers publish quite good information on theory of operation. I'll also keep posting more measurement results over time (for example the 8fs thing is quite apparent from the results when you see aliases around every 352.8/384).

 

For hardware, I've done quite a bunch of studying over the past about 25 years. For software I can only speak of my own algorithms, designed and implemented by me personally.

 

I'm glad you understand.

 

It is just that I find it hard to believe the designer of my DAC is wrong about the things he explains (particularly regarding his own designs, all of which I have used and loved over the years). In view of his track record with me, both his hardware and all of the software he makes -- and in view of the fact that I have not yet heard anything I think matches it, much less bests it -- I tend to think he knows what he's talking about.

 

I'm sure there are different perspectives from different designers. This is audio, after all. ;-}

 

Best regards,

Barry

http://www.soundkeeperrecordings.com

http://www.soundkeeperrecordings.wordpress.com

http://www.barrydiamentaudio.com

[Miska]

In view of his track record with me, both his hardware and all of the software he makes -- and in view of the fact that I have not yet heard anything I think matches it, much less bests it -- I tend to think he knows what he's talking about.

 

I'll refresh my measurements on the AKM (used my Metric Halo), but those have 8x digital filter and 128x oversampling delta-sigma modulator, so the 128/8=16x factor is done other way than digital filter...

 

Check out for example diagram and key features here:

AK4396VF | Product | AKM - Asahi Kasei Microdevices

 

(of course one possibility is that the chip manufacturer doesn't know what their chips do?)

[bdiament]

Hi Miska,

 

I'll refresh my measurements on the AKM (used my Metric Halo), but those have 8x digital filter and 128x oversampling delta-sigma modulator, so the 128/8=16x factor is done other way than digital filter...

 

Check out for example diagram and key features here:

AK4396VF | Product | AKM - Asahi Kasei Microdevices

 

(of course one possibility is that the chip manufacturer doesn't know what their chips do?)

 

I cannot say how the designer of my converters implemented the chip. Only he can.

I can only speak to what I hear when using his designs.

 

Best regards,

Barry

Soundkeeper Recordings

Barry Diament Audio

[Miska]

I cannot say how the designer of my converters implemented the chip.

 

He doesn't implement it, AKM does. He just uses off-the-shelf component and the datasheet downloadable from above link tells exactly the amount of configuration flexibility the chip has...

[bdiament]

Hi Miska,

 

He doesn't implement it, AKM does. He just uses off-the-shelf component and the datasheet downloadable from above link tells exactly the amount of configuration flexibility the chip has...

 

Perhaps you have some knowledge of how he uses the chip. I don't know what he does with it.

I only know how the results sound to me.

 

Do you have a ULN-8? (I thought you run Windows.)

 

Best regards,

Barry

Soundkeeper Recordings

Barry Diament Audio

[Bob Stern]

He told me on-the-fly SRC is generally asynchronous, so it does rate and ratio estimation. Variation in that estimate causes low-level time and frequency dependent distortion that he tells me is likely the source of the brightening and hardening I hear in comparison to off-line SRC.

 

...

 

At the very least, this explains (to me) why I've never responded to oversampling in a converter in the same (negative) way I respond to real-time sample rate conversion using even the most transparent SRC algorithm in my experience.

 

The first paragraph is wrong with respect to SRC performed by computer playback software, such as iZotope SRC in Audirvana. It is synchronous. So the shortcomings of ASRC do not explain why Barry dislikes software-implemented SRC he has heard.

 

 

According to him, synchronous SRC can be made essentially perfect, depending on how many resources one is willing to devote to it. Properly implemented, it is essentially the same as simply digitizing at a different sample rate. When upsampling, new (redundant) data is interpolated. If the upsampling rate is an integer (as with the DACs he uses), the original data stream remains embedded and untouched in the upsampled stream. In fact, you can drop the new interpolated samples from the stream without any additional filtering and still have a valid stream at the lower sample rate.

 

Regarding Miska's point that the input data is not replicated even in integer-ratio synchronous SRC, I suspect BJ was referring to the data at the input of the digital filter, not the output, where 4X upsampling is performed by zero padding.

[Miska]

Perhaps you have some knowledge of how he uses the chip. I don't know what he does with it.

 

Since it's a hardware chip, it functions some particular way inside and the set of configuration options are stated in the datasheet. So the the the things you can change and things you cannot change are very clearly defined. Literally etched on the silicon.

 

Do you have a ULN-8? (I thought you run Windows.)

 

No, I'm not interested on it. I'm particularly interested on DACs (as devices) that people use for listening. And I have couple of devices with AKM chips. And AKM chips especially benefit from SSRC performed prior to the chip (software or hardware).

 

I run Linux, Windows and OS X (in this order) and my software runs on all these three platforms. But my primary development platform is Linux.

[bdiament]

Hi Bob,

 

The first paragraph is wrong with respect to SRC performed by computer playback software, such as iZotope SRC in Audirvana. It is synchronous. So the shortcomings of ASRC do not explain why Barry dislikes software-implemented SRC he has heard...

 

As to whether on-the-fly SRC is generally synchronous, I don't know but since I know this designer and have the greatest respect for his knowledge and his work, if he told me this is the case, I will tend to take his word for it. Again, if I misinterpreted what he told me, it would be my mistake, not his. However, checking over our communications, I believe I got it right.

 

I'm not sure where you got the idea I don't like software-implemented SRC. I use iZotope's algorithm in my work all the time, to create 96k and 44.1k versions of my 192k recordings. When I use it though, it is *always* as an offline process. Perhaps you meant to say I don't like on-the-fly SRC? That would be true.

 

Best regards,

Barry

Soundkeeper Recordings

The Soundkeeper | Audio, Music, Recording, Playback

http://www.barrydiamentuaudio.com

[bdiament]

Hi Miska,

 

...No, I'm not interested on it. I'm particularly interested on DACs (as devices) that people use for listening....

 

I was confused by your earlier post which said:

...I'll refresh my measurements on the AKM (used my Metric Halo)...

 

Perhaps you meant to say used *by* Metric Halo?

FYI, they use different AKM chips in different boxes they make.

 

As far as DACs that folks use for listening, I know quite a few folks, aside from myself, including several on this forum, that use Metric Halo boxes as their DAC -- purely for listening. (I have often told the designer he could sell a lot more of them to folks in the audiophile world if he switched to a 3/8" (~9 mm) thick faceplate and tripled the price. ;-})

 

Best regards,

Barry

Soundkeeper Recordings

The Soundkeeper | Audio, Music, Recording, Playback

Barry Diament Audio

[Miska]

Perhaps you meant to say used *by* Metric Halo?

 

Yes, that was a typo, sorry.

 

FYI, they use different AKM chips in different boxes they make.

 

I know, the basic things in the chips are quite similar, although the AK4399 is quite a big update compared to many previous ones.

 

As far as DACs that folks use for listening, I know quite a few folks, aside from myself, including several on this forum, that use Metric Halo boxes as their DAC -- purely for listening. (I have often told the designer he could sell a lot more of them to folks in the audiophile world if he switched to a 3/8" (~9 mm) thick faceplate and tripled the price. ;-})

 

Maybe, although their overall share on audiophile market is probably way under 1%. From my point of view many other pro-audio companies have bigger share. Prism Orpheus / Lyra being similar products (but different component set, not AKM).

[bdiament]

Hi Miska,

 

...Maybe, although their overall share on audiophile market is probably way under 1%. From my point of view many other pro-audio companies have bigger share. Prism Orpheus / Lyra being similar products (but different component set, not AKM).

 

Actually, there is no maybe about there being a good number of folks who do no recording at all but that use MH boxes as their DACs their personal listening. MH doesn't advertise in audio magazines and other than the editor of one (who does do some recording using their older models), none of the audio magazines has even mentioned them, much less written a review of one. (As I see it, this is their loss. Advertisers of quite a few considerably more expensive units would not be pleased to be put up in direct comparison.)

 

No argument on overall share of the audiophile market. While I wish them maximum success, I never took market share -- in audio or in anything else -- as an indicator of quality. All too often in fact, the relationship turns out to be an inverse one.

 

Best regards,

Barry

Soundkeeper Recordings

The Soundkeeper | Audio, Music, Recording, Playback

Barry Diament Audio

[jamesg11]

Alex, what process is involved in your off-line conversions? What sw are you utilising, etc?

[Superdad]

Alex, what process is involved in your off-line conversions? What sw are you utilising, etc?

 

Well, Sampler Manager is the more straightforward one to use, but their demo version does not enable the iZotope SRC. So I downloaded and tried the demo of the same company's ambitious new suite, Triumph. It is a slick product and does many things far outside what I want to do, which is just to batch upsample a bunch of files using custom iZotope settings.

 

Actually, I think it would be great if a developer would license the iZotope engine and create an easy interface for batch interpolating music files.

 

Just to be clear though, the difference I heard between A+'s realtime upsampling and playback versus the same tracks pre-processed (with the same iZotope settings) with Triumph and then played back via A+ was not huge. It was somewhat similar in character to the difference between A+ playback in "Playlist" mode versus in iTunes integrated mode--only smaller.

Given the massive inconvenience--not to mention the unbelievably massive resultant file sizes--and the fact that one still needs to keep the originals in case you decide to change your SRC filter parameters, I'm not planning to make a habit of doing this. I did do it for a few favorite reference tracks, but that's about it.

I suggest people try this for themselves and see what they hear.

[orgel]

Actually, I think it would be great if a developer would license the iZotope engine and create an easy interface for batch interpolating music files.

 

I'm pretty sure Fidelia Advanced, also from the same company, will do the offline resampling using iZotope.

 

(Links are a little weird on the Audiofile Engineering site, so you'll need to click on "Fidelia Advanced" at right, after following the link.)

 

--David