Jump to content
Superdad

EtherREGEN: We are getting much closer!!

Rate this topic

Recommended Posts

On 8/8/2019 at 8:07 PM, stevebythebay said:

Used both the Sigma and Alpha in my config.  

 

Looking at the specs Shunyata has published for their Ethernet cables, it appears the only difference is the number of CMode modules.  Venom has 0, Alpha has 1 and Sigma has 2.  The EtherRegen should lessen (or eliminate?) the need for any common mode filtering.  It’ll be interesting to hear if the differences between their three Ethernet cables vanish when used with the EtherRegen.


Digital:  Innuos Zenith Std Mk2 > Shunyata Alpha USB > Chord Hugo M-Scaler > Shunyata Alpha S/PDIF > Chord Hugo TT2 

Amp & Speakers:  Spectral DMA-150mk2 > Aerial 10T

Foundation: Stillpoints Ultra, Shunyata Denali power conditioner, Shunyata Alpha power cords, Shunyata Anaconda interconnect, MIT Oracle speaker cables, GIK bass traps

Share this post


Link to post
Share on other sites
2 hours ago, stevebythebay said:

But the proof will be in the “pudding”.

 

True that.

 

I was just struck by the fact that this thread was started in March of 2018.  Hopefully not much longer.


Digital:  Innuos Zenith Std Mk2 > Shunyata Alpha USB > Chord Hugo M-Scaler > Shunyata Alpha S/PDIF > Chord Hugo TT2 

Amp & Speakers:  Spectral DMA-150mk2 > Aerial 10T

Foundation: Stillpoints Ultra, Shunyata Denali power conditioner, Shunyata Alpha power cords, Shunyata Anaconda interconnect, MIT Oracle speaker cables, GIK bass traps

Share this post


Link to post
Share on other sites
3 hours ago, stevebythebay said:

What I’d hope is that for similar cable designs used into/out of the EtherREGEN the noise brought in would dissolve on its way out, preserving whatever attributes the cables might offer, be they good or ill, for the downstream system.  


Whatever you do with cables: Make sure there is no earth connection. That doesn’t rule out plugs with metal, but in general most of them. One example is the Audioquest Vodka that has metal plugs. It will work. Probably heavenly overpriced as most audiophile cables 😀

 

Blue Jeans is a very good choice.  
 

My link previous post another good option. 
 

And please rember, that even it there was a general recommendation for using a one meter cable before, that is NOT the case with EtherRegen. So length shouldn’t matter. Serach Johns post in this tread. Sould be something about it there in details. 

 

So hopefully we can leave the cable discussion dead. It’s a bit OT 😀


However it is relevant whenever there will be a tread about how the EtherRegen sound quality. 

(Ops. A switch with SQ 😀. Yes, that’s that’s what we all expect. And it’s already  proven by OpticalModule, and some other overpriced options). 

 

Share this post


Link to post
Share on other sites
On 8/11/2019 at 10:11 AM, Superdad said:

 

The aluminum cases for the first 250 unit production run are on order--with a promised delivery date of October 2nd.

 

The second round of pre-production boards (discussed here: https://audiophilestyle.com/forums/topic/38968-etherregen-we-are-getting-much-closer/?do=findComment&comment=978513) are due to arrive August 26th.  They may work perfectly, or they may require some (hopefully) small tweaks.  With luck these next boards will be usable for some field beta test.  Once we are satisfied, then we can release into full production.  

 

Please don't try to pin us down any closer to a date at this moment. Just because the cases will arrive at the beginning of October does not mean that is when we will begin shipping.  It really will be 3 weeks after whatever date it is that we release the final boards to production.  Testing first.  Have to get this right.

Thanks for your patience everyone. :D

 

--Alex C.

 

 

I'm just hoping for Santa to bring me one - anything earlier is a bonus. :)

Share this post


Link to post
Share on other sites
On 8/10/2019 at 7:21 PM, kennyb123 said:

 

Looking at the specs Shunyata has published for their Ethernet cables, it appears the only difference is the number of CMode modules.  Venom has 0, Alpha has 1 and Sigma has 2.  The EtherRegen should lessen (or eliminate?) the need for any common mode filtering.  It’ll be interesting to hear if the differences between their three Ethernet cables vanish when used with the EtherRegen.

The Cmode filters are ferrite rings.

Share this post


Link to post
Share on other sites
5 hours ago, marce said:

The Cmode filters are ferrite rings.

 

Where did you get that information?


Digital:  Innuos Zenith Std Mk2 > Shunyata Alpha USB > Chord Hugo M-Scaler > Shunyata Alpha S/PDIF > Chord Hugo TT2 

Amp & Speakers:  Spectral DMA-150mk2 > Aerial 10T

Foundation: Stillpoints Ultra, Shunyata Denali power conditioner, Shunyata Alpha power cords, Shunyata Anaconda interconnect, MIT Oracle speaker cables, GIK bass traps

Share this post


Link to post
Share on other sites
1 hour ago, kennyb123 said:

 

Where did you get that information?

They look like ferrites and that's what you would use on Ethernet cable so you don't add losses and impedance mismatches for the signal. A basic common mode filter is passing the wires through a shared magnetic core of some sort. Pretty basic common practice.

Apologies just read the rest of the thread!

Share this post


Link to post
Share on other sites
1 hour ago, Superdad said:

Pardon me gents, but any further discussion of Ethernet cables will result in my creating a new topic and transferring all such posts over there.  (I am sure there is an existing Ethernet cable thread somewhere, but my forum moderation capability is limited to moving posts to other topics within the UpTone sponsored area.)

Thanks! 

Sorry I sorta’ started this off-topic thread within a thread.  But I felt at the time, and still feel, the importance in all connections in/out of any switch in eventual sound quality.  Please fork this off with the other Ethernet cable bits if you wish. 

 

The Shunyata’s actually focus is on reducing transmission and phase distortion, including high frequency noise distortion.  

 

While awaiting the EtherREGEN, and now the Shunyata cables, I’ve had recourse to plug a Transparent TPM into my system wall plug 

 

https://www.transparentcable.com/collections/power-add-on-surge-protection/products/plug-in-network-protector 

 

connecting the outbound cable from my Cisco 2960 to this device and sending the cleaned-up signal on its way to my dCS gear. It has reduced noise from the upstream path. I’ve no idea if I’d perceive any benefit in using it once I have the Shunyata’s in place. 

 


Steve Schaffer

Roon Nucleus/ WD USB Drive / dCS Vivaldi Upsampler  / dCS Vivaldi DAC / dCS Vivaldi Clock / Spectral DMC-30SV preamp / Spectral DMA-500 monoblocks / Wilson Audio Alexia Series 2 speakers

Share this post


Link to post
Share on other sites
3 hours ago, stevebythebay said:

Sorry I sorta’ started this off-topic thread within a thread.  But I felt at the time, and still feel, the importance in all connections in/out of any switch in eventual sound quality.  Please fork this off with the other Ethernet cable bits if you wish. 

 

The Shunyata’s actually focus is on reducing transmission and phase distortion, including high frequency noise distortion.  

 

While awaiting the EtherREGEN, and now the Shunyata cables, I’ve had recourse to plug a Transparent TPM into my system wall plug 

 

https://www.transparentcable.com/collections/power-add-on-surge-protection/products/plug-in-network-protector 

 

connecting the outbound cable from my Cisco 2960 to this device and sending the cleaned-up signal on its way to my dCS gear. It has reduced noise from the upstream path. I’ve no idea if I’d perceive any benefit in using it once I have the Shunyata’s in place. 

 


You really need to be patient, and purchase the EtherRegen 😀

(Or even two)

 

Share this post


Link to post
Share on other sites
9 minutes ago, mikicasellas said:

Tell her you won it over for the time you waited for it...."It was free Honey, FREEEEE"

 

Normally I beta test “everything” so this will also work :) :) :) 

Everybody wants my feedback lalalala 

#futureFi-is-peace-with-your-wife-Fi 

 

PS: I think the development time is adequate to the attention of detail and very transparent due to the excellent communication. 

 

Share this post


Link to post
Share on other sites
2 hours ago, R1200CL said:


You really need to be patient, and purchase the EtherRegen 😀

(Or even two)

 

Have been and will continue to be patient. My experiences with a number of switches, including my current Cisco, have shown that with both my use of the Transparent device and recent experience with Shunyata Ethernet cables, these switches are clearly producing noise.  So, I fully expect a degree of benefit from the EtherREGEN. 


Steve Schaffer

Roon Nucleus/ WD USB Drive / dCS Vivaldi Upsampler  / dCS Vivaldi DAC / dCS Vivaldi Clock / Spectral DMC-30SV preamp / Spectral DMA-500 monoblocks / Wilson Audio Alexia Series 2 speakers

Share this post


Link to post
Share on other sites

One server solution. Local files are stored on a NAS. The server loads the entire track in RAM before playing. 

Apparently to get the most out of the EtherREGEN, we need the signal to cross the moat. That unfortunately limits one side to 100 Mbps. Some larger DSD files would take quite a long time to load in RAM over a 100 Mbps connection. 

I am thinking what would be the best way to implement the EtherREGEN in such case? 

 

So far, this is the best idea I have come up with:

EtherREGEN.thumb.jpg.d34b9a5ce4f179f7a73b184a13d97485.jpg

 

Streaming Tidal / Qobuz would go across the moat, that would be quite beneficial. 

Loading tracks from the NAS to the RAM on the music server would have to be done over 1Gbps connection. No crossing the moat, so not using the most benefits of the switch. But adding an opticalModule would help isolating the noise from the NAS and would also do some reclocking (not as good as EtherREGEN if I understand correctly, but at least better than nothing). The JCAT NIC also has a good clock, so perhaps that would be an acceptable compromise for this use case. 

 

@Superdad @JohnSwenson - do you have any better suggestions? 

 

Thank you. 

Share this post


Link to post
Share on other sites

I would point the 100b at the music server, and point the 1gb (copper and optical) ports at every thing else. The point of the moat is to separate the “player” from the rest of the network.

 

I plan for the etherRegen to be the cleanup for my network, with the most isolation, and final reclocking for the port going directly to the player.

 

I use my NAS as a Roon server, and my Streamer/DAC for an endpoint. (No USB)


[Home Digital] Bricasti M12 > McIntosh MC60 > Zu Druid V + Undertone (BHSE + Voce)

[Home Analog] Technics SL-1200G > K&K Audio Phono Amp (Zu DL-103/Benz Glider-SL/Denon DL-301 II)

[Office] Laptop > Kitsune R2R lvl3 > Violectric V281 > Focal Utopia Headphones (balanced)

[beach/Travel] Laptop > DragonFly Red > Ether Headphones

Share this post


Link to post
Share on other sites
2 minutes ago, Bones13 said:

 

I would point the 100b at the music server, and point the 1gb (copper and optical) ports at every thing else.

 

 

And I would have to wait a minute after every track until the next one loads in RAM over the 100 Mbps connection. 

If it was not clear from my post - I am trying to avoid the traffic from the NAS to my server to go over 100 Mbps connection.

Share this post


Link to post
Share on other sites
1 hour ago, Nenon said:

One server solution. Local files are stored on a NAS. The server loads the entire track in RAM before playing. 

Apparently to get the most out of the EtherREGEN, we need the signal to cross the moat. That unfortunately limits one side to 100 Mbps. Some larger DSD files would take quite a long time to load in RAM over a 100 Mbps connection. 

I am thinking what would be the best way to implement the EtherREGEN in such case? 

 

So far, this is the best idea I have come up with:

EtherREGEN.thumb.jpg.d34b9a5ce4f179f7a73b184a13d97485.jpg

 

Streaming Tidal / Qobuz would go across the moat, that would be quite beneficial. 

Loading tracks from the NAS to the RAM on the music server would have to be done over 1Gbps connection. No crossing the moat, so not using the most benefits of the switch. But adding an opticalModule would help isolating the noise from the NAS and would also do some reclocking (not as good as EtherREGEN if I understand correctly, but at least better than nothing). The JCAT NIC also has a good clock, so perhaps that would be an acceptable compromise for this use case. 

 

@Superdad @JohnSwenson - do you have any better suggestions? 

 

Thank you. 

 

As others have said, assign your Music Server to the 100Mbit/sec output port because even the highest definition stereo music only needs a couple of Mbits/sec. 4K video, the current most demanding service only needs around 25Mbit/sec.

 

The way you have your design you will create a bottleneck in your network, exactly what you say you want to avoid.

 

In fact, I will be running fibre from my main switch to the EtherREGEN (stereo is about 25 metres from switch on another floor) then using copper from the 100Mbit/sec port on the EtherREGEN to the UltraRendu and then onto the Chord DAVE. If my understanding is correct, this was one of the design intentions.

 

Regards

GG

Share this post


Link to post
Share on other sites
22 minutes ago, GryphonGuy said:

 

As others have said, assign your Music Server to the 100Mbit/sec output port because even the highest definition stereo music only needs a couple of Mbits/sec. 4K video, the current most demanding service only needs around 25Mbit/sec.

 

The way you have your design you will create a bottleneck in your network, exactly what you say you want to avoid.

 

In fact, I will be running fibre from my main switch to the EtherREGEN (stereo is about 25 metres from switch on another floor) then using copper from the 100Mbit/sec port on the EtherREGEN to the UltraRendu and then onto the Chord DAVE. If my understanding is correct, this was one of the design intentions.

 

Regards

GG

 

I guess I need to explain how pre-loading in RAM is different than streaming.

 

Not all the DSD files are that big, but some are. Let's take an extreme case. It takes over 80 seconds to transfer a 1GB file over 100 Mbps connection. So let's say hypothetically that I have an album with 10 DSD tracks of that size. Here is what happens:

- I click play.

- I wait 80+ seconds for the file to load in RAM. 

- The track start playing. The music stops at the end of the track.

- The second track starts loading.

- I wait 80+ seconds for the second track to load.

- Repeat the same process above for the rest of the tracks... 

 

1 GB file is a very extreme case. Most of my files are much smaller. Let's say an average file is 150 MB. That is still a 12+ seconds gap between tracks. That would be quite an unpleasant experience over 100 Mbps connection. If we bump it up to 1 Gbps connection the gap would be just a little over a second on an average file size. 

Share this post


Link to post
Share on other sites
3 hours ago, Nenon said:

 

I guess I need to explain how pre-loading in RAM is different than streaming.

 

Not all the DSD files are that big, but some are. Let's take an extreme case. It takes over 80 seconds to transfer a 1GB file over 100 Mbps connection. So let's say hypothetically that I have an album with 10 DSD tracks of that size. Here is what happens:

- I click play.

- I wait 80+ seconds for the file to load in RAM. 

- The track start playing. The music stops at the end of the track.

- The second track starts loading.

- I wait 80+ seconds for the second track to load.

- Repeat the same process above for the rest of the tracks... 

 

1 GB file is a very extreme case. Most of my files are much smaller. Let's say an average file is 150 MB. That is still a 12+ seconds gap between tracks. That would be quite an unpleasant experience over 100 Mbps connection. If we bump it up to 1 Gbps connection the gap would be just a little over a second on an average file size. 

 

Interesting scenario. I certainly have tracks that exceed 1GB in size. Are you referring to Stylus on Euphony OS - i.e. "Buffer before playing = 100%"?

 

If so, while it is definitely true you'll incur the pre-load delay for the first track, it should not be an issue for subsequent tracks. Especially if you've also set the "Use Cache"  flag. In that case, all tracks that are added to the Queue start getting loaded into the local filesystem cache, from where they are then loaded to RAM for playback. While you'll wait for the first track to transfer, the remaining tracks will transfer while you're listening. Additionally, the gapless playback algorithm in Stylus preloads the next track (from cache), so you really don't have to incur the delays on every track.

 

That said, another place I've found 100Mbps to be limiting is during system upgrades, especially if it involves a full OS upgrade of the DAC-attached endpoint/server.

 

Presumably, if you keep the NAS and the music server on the same side of the moat, while you don't get isolation, I'm guessing you still get reclocking?

 

Good question.

Share this post


Link to post
Share on other sites
1 hour ago, austinpop said:

Interesting scenario. I certainly have tracks that exceed 1GB in size. Are you referring to Stylus on Euphony OS - i.e. "Buffer before playing = 100%"?

 

If so, while it is definitely true you'll incur the pre-load delay for the first track, it should not be an issue for subsequent tracks. Especially if you've also set the "Use Cache"  flag. In that case, all tracks that are added to the Queue start getting loaded into the local filesystem cache, from where they are then loaded to RAM for playback. While you'll wait for the first track to transfer, the remaining tracks will transfer while you're listening. Additionally, the gapless playback algorithm in Stylus preloads the next track (from cache), so you really don't have to incur the delays on every track.

 

It was an exaggerated example, mainly for illustration purposes to the responses saying that 100Mbps is more than enough. Yes, I am using Euphony at the moment, and the example I gave is not exactly how Euphony works.

 

This is getting a little offtopic, so if @Superdad decides to delete, please go ahead. 

 

The gapless playback algorithm in Euphony definitely helps with slower bandwidth. But I have also noticed that those Euphony background processes decrease the sound quality in my system, even with the powerful i9-9900K CPU. They consume very little of the CPU, but it is still an audible decrease in sound. In some cases when I see more than a couple of cores using over 1% CPU, I would restart the Euphony app (which kills most background processes) and all of a sudden the magic comes back a few seconds later. And the sound becomes much better. I have done this a number of times and the effect is always the same. 

So while the gapless playback algorithm does what the name says - it works in the background to cache all tracks from the playlist to my Euphony cache drive (i.e. a partition on my Optane card), it also decreases the sound quality. Obviously the longer it runs, the worse the effects are... or I should say the longer the negative impact of this background process is sustained for.

In my example of 10 large DSD tracks, once you click play, you would wait 80+ seconds for the first track to start playing, and then in the next 12-15 minutes a background process would be downloading the rest of the album to my Optane card. So somewhere around the end of track #2 or #3 the sound quality would become optimal. Or at least that's what I would experience in my system. I would like to reduce that negative impact 10 times by using 1 Gbps instead of 100 Mbps. 

 

But here is a more simple example - Let's say I want to browse my library and jump from one album to another. That would be a painful experience with "Buffer before playing = 100%" enabled for the tracks that are not yet cached. I may have to wait 80+ seconds for every track I click on. Or maybe not 80+ but you get the point. I have used an industrial grade 100 Mbps fiber media convertor which sounded great (especially after I upgraded its power supply caps and fed by a good LPS), and have experienced that with Euphony. If I added a bunch of new albums to my library and wanted to quickly scan through them, I had to either bypass the 100 Mbps media convertor or disable the "Buffer before playing = 100%" option. In some cases I ended up switching from Stylus to Roon. Roon has no issues with 100 Mbps bandwidth but it just does not as good. 

 

Hopefully that adds a little more clarity as to why I asked my original question. 

5 hours ago, Nenon said:

One server solution. Local files are stored on a NAS. The server loads the entire track in RAM before playing. 

Apparently to get the most out of the EtherREGEN, we need the signal to cross the moat. That unfortunately limits one side to 100 Mbps. Some larger DSD files would take quite a long time to load in RAM over a 100 Mbps connection. 

I am thinking what would be the best way to implement the EtherREGEN in such case? 

 

So far, this is the best idea I have come up with:

EtherREGEN.thumb.jpg.d34b9a5ce4f179f7a73b184a13d97485.jpg

 

Streaming Tidal / Qobuz would go across the moat, that would be quite beneficial. 

Loading tracks from the NAS to the RAM on the music server would have to be done over 1Gbps connection. No crossing the moat, so not using the most benefits of the switch. But adding an opticalModule would help isolating the noise from the NAS and would also do some reclocking (not as good as EtherREGEN if I understand correctly, but at least better than nothing). The JCAT NIC also has a good clock, so perhaps that would be an acceptable compromise for this use case. 

 

@Superdad @JohnSwenson - do you have any better suggestions? 

 

Thank you. 

 

I can think of a few different ways of doing that but wanted to hear from the experts who designed the EtherREGEN if they have a prefered solution for that scenario. It's clear that crossing the moat gives best results and that the best thing to do is not to connect anything on the side where the server resides. But given the @JohnSwenson designed both, the EtherREGEN and the opticalModule, he might have some inside knowledge of what might work best. 

 

Regardless of the outcome, I am still getting an EtherREGEN as soon as I could get my hands on one /we are really hoping for this October(EtherREGEN)Fest :)/. . And trying in my system would be the best way to find out what works best for me. If that's the answer, I accept it, but it does not hurt asking, right? :)

 

 

 

 

 

Share this post


Link to post
Share on other sites
1 hour ago, Nenon said:

 

It was an exaggerated example, mainly for illustration purposes to the responses saying that 100Mbps is more than enough. Yes, I am using Euphony at the moment, and the example I gave is not exactly how Euphony works.

 

This is getting a little offtopic, so if @Superdad decides to delete, please go ahead. 

 

The gapless playback algorithm in Euphony definitely helps with slower bandwidth. But I have also noticed that those Euphony background processes decrease the sound quality in my system, even with the powerful i9-9900K CPU. They consume very little of the CPU, but it is still an audible decrease in sound. In some cases when I see more than a couple of cores using over 1% CPU, I would restart the Euphony app (which kills most background processes) and all of a sudden the magic comes back a few seconds later. And the sound becomes much better. I have done this a number of times and the effect is always the same. 

So while the gapless playback algorithm does what the name says - it works in the background to cache all tracks from the playlist to my Euphony cache drive (i.e. a partition on my Optane card), it also decreases the sound quality. Obviously the longer it runs, the worse the effects are... or I should say the longer the negative impact of this background process is sustained for.

In my example of 10 large DSD tracks, once you click play, you would wait 80+ seconds for the first track to start playing, and then in the next 12-15 minutes a background process would be downloading the rest of the album to my Optane card. So somewhere around the end of track #2 or #3 the sound quality would become optimal. Or at least that's what I would experience in my system. I would like to reduce that negative impact 10 times by using 1 Gbps instead of 100 Mbps. 

 

But here is a more simple example - Let's say I want to browse my library and jump from one album to another. That would be a painful experience with "Buffer before playing = 100%" enabled for the tracks that are not yet cached. I may have to wait 80+ seconds for every track I click on. Or maybe not 80+ but you get the point. I have used an industrial grade 100 Mbps fiber media convertor which sounded great (especially after I upgraded its power supply caps and fed by a good LPS), and have experienced that with Euphony. If I added a bunch of new albums to my library and wanted to quickly scan through them, I had to either bypass the 100 Mbps media convertor or disable the "Buffer before playing = 100%" option. In some cases I ended up switching from Stylus to Roon. Roon has no issues with 100 Mbps bandwidth but it just does not as good. 

 

Hopefully that adds a little more clarity as to why I asked my original question. 

 

I can think of a few different ways of doing that but wanted to hear from the experts who designed the EtherREGEN if they have a prefered solution for that scenario. It's clear that crossing the moat gives best results and that the best thing to do is not to connect anything on the side where the server resides. But given the @JohnSwenson designed both, the EtherREGEN and the opticalModule, he might have some inside knowledge of what might work best. 

 

Regardless of the outcome, I am still getting an EtherREGEN as soon as I could get my hands on one /we are really hoping for this October(EtherREGEN)Fest :)/. . And trying in my system would be the best way to find out what works best for me. If that's the answer, I accept it, but it does not hurt asking, right? :)

 

 

 

 

 

One thing to consider is that your current situation of sending music through the Ethernet while playing significantly degrades sound may in fact go away when using an EtherREGEN, that is in fact its primary purpose, to get rid of anything coming over the network that will degrade sound.  It seems like your assumption is that the degradation is coming from the renderer itself having to deal with the data rather than from what is coming over the connection itself. It's hard to tell exactly which it is.

 

The EtherREGEN may clean up the external degradation so much that having music data coming over the wire wile it is being played does not cause any degradation. Or there still might be some effect from the renderer's  electronics itself. That's going to be hard to tell until you try it. 

 

Unfortunately there is no way anyone can tell you exactly how it is going to turn out in any situation, the fully functional EtherREGEN simply does not exist at this point in time. Even if I had all the equipment you have I couldn't test it since I don't have a fully functional board at this point. I'm not trying hide things or be difficult, It just cannot be done right now. There is no way I can tell yow what configuration is going to sound best. There is just no way I can do that right now. Any attempt at making a pure guess would be a disservice to the community.

 

It seems to me that the best way to deal with this, is wait until you have an EtherREGEN, then try it in the different modes, see if prebuffering everything before playing is in fact better than data coming over while playing, THEN we have some information to start coming up with scenarios for testing to find out what ultimately is best for you.

 

John S.

Share this post


Link to post
Share on other sites

Maybe a bit OT, but somehow still relevant IMO if the ability of using a device is asked for.  

 

What SQ can be gained in reality by playing those extremely big files (and on ram) compared to more normal sized hi-res? The extra storage, transference, re-clocking, buffering, conversion, more clocking, more transfer and calculation of merely more zeros. This extra transfer, clocking and processing of zeros takes place multiple times in a digital streaming audio chain before the final Digital -> Analogue conversion.

 

The amount of small details that can be recorded and proceeded in a recording studio or live concert is reached and exceeded with 96 KHz 24 bit recordings. Left is the digital filtering that can be done in higher frequency if we make the files bigger by adding more zeros. If filtering in higher MHz would be better will say.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...