Topic: DAW systems explained! (Read 6540 times)

ammitsboel · « **on:** March 12, 2005, 07:07:06 PM »

Hi everyone,

Is there anyone in here that can explain everything about audio and DAW systems?
What I want to know is what happens to a digital audio signal(AES/EBU) when passed through a DAW's AES/EBU input and recorded to the HD.

My system consist of a windows XP PC with Sequoia and Lynx AES16, I'm using ASIO drivers. Is there any form of error correction(or other processing) that takes place when I perform what I've written above? In other words is there a way of recording a digital signal to the HD of a DAW precisely and exactly in every detail without any F****** digital processing, error correcting or any of the other things that make it "better". I say again, so that the samples from the digital signal are recorded, bit for bit, exactly without any loss, adjustment, tinkering or anything at all onto the hard drive.

I hope there is someone that can explain what exactly happens to the signal?

Best Regards

TotalSonic · « **Reply #1 on:** March 12, 2005, 07:26:45 PM »

Depending on the soundcard and ASIO drive implementation one thing that ASIO might be doing math wise that does not happen with MME is that it converts fixed point numbers to floating point.

fwiw - Bob Lentini, SAWStudio's author and a person I consider the best DAW app programmer around, has been pretty critical of the ASIO protocol, even though he added support for it a few years back.

Here's some quotes in response to the reasons he doesn't like it:

ASIO... I don't like the loosness of it... drivers try to control the app... it should be the other way around, in my opinion.... the driver simply needs to move data to and from ram as efficiently as possible... not take control of everything and dictate buffer formats and sizes etc to the app.

Too many formats... too much splitting and merging of data, in all kinds of possible formats... the app needs to try to handle way too many possibilities... its very complex inside an engine like SAWStudio...

ASIO is too easily stepped on by Windows and other threads... there is no room whatsoever for any interruptions in data flow... which will ALWAYS happen at the most inopportune times in Windows... when it does... ASIO spits out repeats of the last buffer... horrible sound...

I won't touch true WDM... its probably the worst driver model I've ever fooled with...

At least with the MME, I can control sending multiple buffers ahead when I know Windows might interfere with data flow... like when its about to repaint 15 windows onscreen... or when the app is about to minimize...etc..

With ASIO... there is only one buffer playing... and one filling... any interruptions whatsoever... and you have a glitch... and a nasty one at that in most cases...

With DWave... everything is different... DWave does not require any communication between the app and driver during playback or record... no thread interruptions... no context switching between Rings... the driver already knows where to look for the data and pulls it at its own hardware rate without needing to interrupt Windows in any way to ask the app for the next buffer... the app fills the buffers as far in front as it wants... when it wants... without any need to talk to the driver directly during playback or record... the difference is beyond better... at least in my opinion.

Heh.... you asked.

Best regards,
Steve Berson

ammitsboel · « **Reply #2 on:** March 12, 2005, 07:39:21 PM »

Thanks Steve!
I wonder how one could get DWave to work with Sequoia Laughing

TotalSonic · « **Reply #3 on:** March 12, 2005, 07:45:02 PM »

ammitsboel wrote on Sun, 13 March 2005 00:39

Thanks Steve!
I wonder how one could get DWave to work with Sequoia Laughing

ummm... yup no go there -
DWave is a protocol proprietary to SAWStudio and the only soundcard support for it is in the current Sydec products (Mixtreme 192 & Mixpander) and a beta driver that was out for the old Sonorus StudI/O card.

I have a Lynx One for it's AES i/o in my mastering DAW and fwiw sometimes it does indeed sound like using the MME driver gives a tiny bit better sounding playback than using ASIO. I haven't tested this blindly yet though to see whether I really can tell the difference.

Best regards,
Steve Berson

bblackwood · « **Reply #4 on:** March 12, 2005, 09:20:58 PM »

TotalSonic wrote on Sat, 12 March 2005 18:45

I haven't tested this blindly yet though to see whether I really can tell the difference.

I'd love to hear the results of that...

bblackwood · « **Reply #5 on:** March 12, 2005, 09:22:11 PM »

ammitsboel wrote on Sat, 12 March 2005 18:07

I hope there is someone that can explain what exactly happens to the signal?

Are you hearing issues?

zetterstroem · « **Reply #6 on:** March 13, 2005, 01:42:28 AM »

the solution Laughing

ammitsboel · « **Reply #7 on:** March 13, 2005, 02:09:20 AM »

bblackwood wrote on Sun, 13 March 2005 02:22

ammitsboel wrote on Sat, 12 March 2005 18:07

I hope there is someone that can explain what exactly happens to the signal?

Are you hearing issues?

Yes, I'm hearing a slight loss of clarity when doing an AES/EBU loop out of the system and in again.

bobkatz · « **Reply #8 on:** March 13, 2005, 07:57:31 AM »

ammitsboel wrote on Sun, 13 March 2005 02:09

bblackwood wrote on Sun, 13 March 2005 02:22

ammitsboel wrote on Sat, 12 March 2005 18:07

I hope there is someone that can explain what exactly happens to the signal?

Are you hearing issues?

Yes, I'm hearing a slight loss of clarity when doing an AES/EBU loop out of the system and in again.

OK, now we're getting down to it! Have you confirmed the data is identical in the loop with no gear in the loop, just a cable? That should be easy for you to do (capture the file, null the signal against the original).

Are you doing your listening to the loop "live", or comparing a file which is played back from the looping?

Next is your DAW locked on internal sync? If it's on internal, and you are hearing a loss of clarity with a live loop, then blame your DAW, your soundcard to be exact. It's not clocking properly. Where is your DAC connected and how?

We're going to get to the bottom of this!!!!!

BK

ammitsboel · « **Reply #9 on:** March 13, 2005, 08:33:00 AM »

bobkatz wrote on Sun, 13 March 2005 12:57

OK, now we're getting down to it! Have you confirmed the data is identical in the loop with no gear in the loop, just a cable? That should be easy for you to do (capture the file, null the signal against the original).

Yes I'm using just an AES/EBU cable, It nulls perfectly in Sequoia.

bobkatz wrote on Sun, 13 March 2005 12:57

Are you doing your listening to the loop "live", or comparing a file which is played back from the looping?

I'm comparing a file witch is played back.

bobkatz wrote on Sun, 13 March 2005 12:57

Next is your DAW locked on internal sync? If it's on internal, and you are hearing a loss of clarity with a live loop, then blame your DAW, your soundcard to be exact. It's not clocking properly. Where is your DAC connected and how?

I've tried with internal/external sync, same results.

I've also tried burning the original + the looped file on a CDR and listened on other systems. Other People has also confirmed this blindly.

Thanks for helping.

Best Regards

bobkatz · « **Reply #10 on:** March 13, 2005, 11:36:59 AM »

ammitsboel wrote on Sun, 13 March 2005 08:33

I'm comparing a file witch is played back.

So, hmmmm... under identical clocking, on internal sync, a file which has the identical data as another file, sounds different to you than the other file?

BK

TotalSonic · « **Reply #11 on:** March 13, 2005, 11:52:35 AM »

Henrik -
Since it seems that you have time to conduct these tests and right now I don't (as when I go in tomorrow there's a week's backlog of vinyl cutting I have to start getting through as quick as possible) -
could you try a/b'ing the following variables:
1) using MME driver protocol vs. ASIO
2) increasing / decreasing the soundcard's output buffer sizes
3) download the SAWStudio demo at http://www.sawstudio.com/downloads/SAWStudioDemo_39c.exe
(and while you're at it since I hate the default look of SAW download my favorite "skin" at http://www.sawstudio.com/downloads/SAWStudio_Contemporary_Sh ade_31.exe )
and compare playback blindly of both the variables above in both Sequoia vs. SAW

Basically - you shouldn't hear any differences whatsoever - but still I'd be mighty curious as to your results.

Best regards,
Steve Berson

ammitsboel · « **Reply #12 on:** March 13, 2005, 12:32:54 PM »

bobkatz wrote on Sun, 13 March 2005 16:36

ammitsboel wrote on Sun, 13 March 2005 08:33

I'm comparing a file witch is played back.

So, hmmmm... under identical clocking, on internal sync, a file which has the identical data as another file, sounds different to you than the other file?

BK

Yes, that's correct.
However I'm in doubt about if the null test actually works. I should try some other applications to match the files and see if i get the same.

Best regards

bblackwood · « **Reply #13 on:** March 13, 2005, 02:20:17 PM »

What sort of DAC are you using, Henrik?

Homero · « **Reply #14 on:** March 13, 2005, 02:57:44 PM »

I have a variation of the theme here.
I have started to use a cheap M-Audio Firewire interface to speedy up some tasks related to SRC.
That interface uses an ASIO driver and Digital Performer supports it.

My chain is:

M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing...

I believe that the dCS 972 D/D at the middle of the chain is breaking the clock chain and feeding the D/A converter with a cleaner clock. Is that correct?

I did some listening tests playing the same material through Sonic HD (without Up-sampler) and from the M-Audio Card through the chain above (with Up-Sampler) and I have liked the result. (I have used the same D/A converter for the two systems)

Best Regards

ammitsboel · « **Reply #15 on:** March 13, 2005, 03:05:55 PM »

bblackwood wrote on Sun, 13 March 2005 19:20

What sort of DAC are you using, Henrik?

I'm using an Audio Note DAC 5.
It's a non oversampling type of DAC.

ammitsboel · « **Reply #16 on:** March 13, 2005, 03:11:57 PM »

Homero wrote on Sun, 13 March 2005 19:57

My chain is:

M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing...

Why do you upsample before the DAC?
Putting another device in the signal chain will always sound different... some more artificial than others.

Do you like this better because it sounds smoother or because it sounds more like the original material?

Best Regards

Homero · « **Reply #17 on:** March 13, 2005, 03:49:06 PM »

ammitsboel wrote on Sun, 13 March 2005 17:11

Homero wrote on Sun, 13 March 2005 19:57

My chain is:

M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing...

Why do you upsample before the DAC?
Putting another device in the signal chain will always sound different... some more artificial than others.

Do you like this better because it sounds smoother or because it sounds more like the original material?

Best Regards

I didn't like the sound when the card in internal clock was feeding the D/A directly, so I tried the upsample / re-clocking
After the upsample the sound is more alike the original, it retains better the spacial information of the original.
I think it is clock issue, I can not blindly trust the clock of that card

Best Regards

ammitsboel · « **Reply #18 on:** March 13, 2005, 04:29:51 PM »

Homero wrote on Sun, 13 March 2005 20:49

I didn't like the sound when the card in internal clock was feeding the D/A directly, so I tried the upsample / re-clocking
After the upsample the sound is more alike the original, it retains better the spacial information of the original.
I think it is clock issue, I can not blindly trust the clock of that card

It sounds very odd to me that a re-sampling would sound better than the original sample length?

Homero · « **Reply #19 on:** March 13, 2005, 05:09:55 PM »

ammitsboel wrote on Sun, 13 March 2005 18:29

Homero wrote on Sun, 13 March 2005 20:49

I didn't like the sound when the card in internal clock was feeding the D/A directly, so I tried the upsample / re-clocking
After the upsample the sound is more alike the original, it retains better the spacial information of the original.
I think it is clock issue, I can not blindly trust the clock of that card

It sounds very odd to me that a re-sampling would sound better than the original sample length?

For me too, after all there is no new information added. But we have to consider the clock issue here. After the SRC there will be a new clock driving the D/A, unrelated with that output-ed by the card. So I think it's possible that with upsampler we can obtain (maybe not always) a better reproduction of the original data.
It is not the same case when you do a SRC with some software like Barbabatch, there is no clock there.
In this case the upsampler and re-clocking processes are occurring in real time and you are converting to analog.

Best Regards

bobkatz · « **Reply #20 on:** March 13, 2005, 09:06:08 PM »

Homero wrote on Sun, 13 March 2005 14:57

I have a variation of the theme here.
I have started to use a cheap M-Audio Firewire interface to speedy up some tasks related to SRC.
That interface uses an ASIO driver and Digital Performer supports it.

My chain is:

M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing...

I believe that the dCS 972 D/D at the middle of the chain is breaking the clock chain and feeding the D/A converter with a cleaner clock. Is that correct?

Well, first of all, I'm pretty darn skeptical about the concept of upsampling in front of what is already an oversampling DAC in the first place! DCS should and could build all of that into the DAC with a single filtering system instead of rooking you for thousands of thousands of unnecessary dollars. I've heard a possible "improvement" using the 972, but as far as I'm concerned, it is totally unnecessary if DCS did their homework and did it right.

Secondly, you are NEVER really "breaking" a clock chain unless the sample rate converter is an asynchronous model. But since the DCS 972 is a synchronous sample rate converter its output rate is slaved by a ratio to the input rate and to the input PLL of the 972. The answer to your question of stability of the clock on the output of the 972 depends strictly on the quality of the Phase locked loop on the input of the DCS 972. It can be good, it can be bad, it can improve the jitter issue or make it worse. But the 972 has a good reputation for a good PLL, so it is probably attenuating the jitter on its input to a good extent. That's what you really meant by saying "breaking the clock chain", all it really means is the DCS 972 is attenuating its input jitter. And once again, DCS is charging you for something they should do better within the DAC! The DAC itself should contain a super quality PLL and there is no technical reason, other than DCS's pocketbook, why an additional "jitter reduction unit" should ever be needed in front of the DAC. If it does perform better, it is because the DAC itself is not built well enough.

But there is an even better choice you are better off making if it is possible to do this patch. DCS is extremely flexible in its clocking options. I believe that the DCS DAC allows you an option where it is the master and that can drive the wordclock of the 972, which can possibly work backwards and drive the M-Audio on external sync. Investigate that option, it will make the DAC stable as a rock.

Then the A/D on the other side of the analog processing can be on internal sync if it is feeding an additional (independent) DAW, which would be your best case, a win-win situation, you are running internal clock for both converters. It would be your case anyway if you are running a different rate in the A/D.

But if you are feeding your A/D back into the same DAW, then your best choice is to put the a/D on internal sync, lock the M Audio to that, and then you are forced to lock the DAC to the M Audio with whatever help the 972 provides.

Hope this helps!

BK

Homero · « **Reply #21 on:** March 14, 2005, 05:22:43 AM »

bobkatz wrote on Sun, 13 March 2005 23:06

Homero wrote on Sun, 13 March 2005 14:57

I have a variation of the theme here.
I have started to use a cheap M-Audio Firewire interface to speedy up some tasks related to SRC.
That interface uses an ASIO driver and Digital Performer supports it.

My chain is:

M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing...

I believe that the dCS 972 D/D at the middle of the chain is breaking the clock chain and feeding the D/A converter with a cleaner clock. Is that correct?

Well, first of all, I'm pretty darn skeptical about the concept of upsampling in front of what is already an oversampling DAC in the first place! DCS should and could build all of that into the DAC with a single filtering system instead of rooking you for thousands of thousands of unnecessary dollars. I've heard a possible "improvement" using the 972, but as far as I'm concerned, it is totally unnecessary if DCS did their homework and did it right.

Secondly, you are NEVER really "breaking" a clock chain unless the sample rate converter is an asynchronous model. But since the DCS 972 is a synchronous sample rate converter its output rate is slaved by a ratio to the input rate and to the input PLL of the 972. The answer to your question of stability of the clock on the output of the 972 depends strictly on the quality of the Phase locked loop on the input of the DCS 972. It can be good, it can be bad, it can improve the jitter issue or make it worse. But the 972 has a good reputation for a good PLL, so it is probably attenuating the jitter on its input to a good extent. That's what you really meant by saying "breaking the clock chain", all it really means is the DCS 972 is attenuating its input jitter. And once again, DCS is charging you for something they should do better within the DAC! The DAC itself should contain a super quality PLL and there is no technical reason, other than DCS's pocketbook, why an additional "jitter reduction unit" should ever be needed in front of the DAC. If it does perform better, it is because the DAC itself is not built well enough.

But there is an even better choice you are better off making if it is possible to do this patch. DCS is extremely flexible in its clocking options. I believe that the DCS DAC allows you an option where it is the master and that can drive the wordclock of the 972, which can possibly work backwards and drive the M-Audio on external sync. Investigate that option, it will make the DAC stable as a rock.

Then the A/D on the other side of the analog processing can be on internal sync if it is feeding an additional (independent) DAW, which would be your best case, a win-win situation, you are running internal clock for both converters. It would be your case anyway if you are running a different rate in the A/D.

But if you are feeding your A/D back into the same DAW, then your best choice is to put the a/D on internal sync, lock the M Audio to that, and then you are forced to lock the DAC to the M Audio with whatever help the 972 provides.

Hope this helps!

BK

Thank you very much Bob, I need some more time to investigate this patch and as soon as possible I will be reporting the results.
I didn't brought the dCS 972 only to do this work so I think its worth the investment.

I would like to clarify one point more:

The digital output of the M-Audio Interface is SPDIF only, so I can't interface directly with the 954 D/A that has only AES Ins.

Roland Storch · « **Reply #22 on:** March 14, 2005, 02:44:44 PM »

TotalSonic wrote on Sun, 13 March 2005 00:26

Depending on the soundcard and ASIO drive implementation one thing that ASIO might be doing math wise that does not happen with MME is that it converts fixed point numbers to floating point.

fwiw - Bob Lentini, SAWStudio's author and a person I consider the best DAW app programmer around, has been pretty critical of the ASIO protocol, even though he added support for it a few years back.

Here's some quotes in response to the reasons he doesn't like it:

ASIO... I don't like the loosness of it... drivers try to control the app... it should be the other way around, in my opinion.... the driver simply needs to move data to and from ram as efficiently as possible... not take control of everything and dictate buffer formats and sizes etc to the app.

ASIO is too easily stepped on by Windows and other threads... there is no room whatsoever for any interruptions in data flow... which will ALWAYS happen at the most inopportune times in Windows... when it does... ASIO spits out repeats of the last buffer... horrible sound...

With ASIO... there is only one buffer playing... and one filling... any interruptions whatsoever... and you have a glitch... and a nasty one at that in most cases...

Best regards,
Steve Berson

If ASIO has all these problems, how do DAWs like Soundscape, Sadie or Mac based Sonic handle that. Do they also have these problems with interruptions in data flow or the right buffer size?

TotalSonic · « **Reply #23 on:** March 14, 2005, 09:36:45 PM »

Roland Storch wrote on Mon, 14 March 2005 19:44

If ASIO has all these problems, how do DAWs like Soundscape, Sadie or Mac based Sonic handle that. Do they also have these problems with interruptions in data flow or the right buffer size?

From my understanding it's a problem with the way priority threading is handled in Windows - so all apps using ASIO2 with Windows are subject to this problem. I don't know the internals of OSX so I can't answer in regards to current Mac apps.

You'll only truly hear the glitching Bob L. is describing in an obvious way if you try and run latencies extremely low - i.e. 1 buffer of 64 samples - and then start loading the cpu up and start doing things like scrolling up and down tracks (i.e. forcing Windows to do quick screen redraws). With his DWave protocol (I have a Mixtreme card for my home project studio's DAW so I've tested this stuff) you can load the session, run at a low latency, and then scroll around like mad and things won't break up like they will using ASIO2 if you get to the "edge"of cpu and track load. Mind you that with SAWStudio that means a heckuva lot of tracks running a heckuva lot of processes to get to this point - something that I am sure no one in a mastering environment ever gets close to. Still makes you wonder - can there be a point where glitches from thread interruptions not be obvious but still exist???

Best regards,
Steve Berson

Ronny · « **Reply #24 on:** March 14, 2005, 11:05:38 PM »

TotalSonic wrote on Mon, 14 March 2005 21:36

Roland Storch wrote on Mon, 14 March 2005 19:44

If ASIO has all these problems, how do DAWs like Soundscape, Sadie or Mac based Sonic handle that. Do they also have these problems with interruptions in data flow or the right buffer size?

From my understanding it's a problem with the way priority threading is handled in Windows - so all apps using ASIO2 with Windows are subject to this problem. I don't know the internals of OSX so I can't answer in regards to current Mac apps.

You'll only truly hear the glitching Bob L. is describing in an obvious way if you try and run latencies extremely low - i.e. 1 buffer of 64 samples - and then start loading the cpu up and start doing things like scrolling up and down tracks (i.e. forcing Windows to do quick screen redraws). With his DWave protocol (I have a Mixtreme card for my home project studio's DAW so I've tested this stuff) you can load the session, run at a low latency, and then scroll around like mad and things won't break up like they will using ASIO2 if you get to the "edge"of cpu and track load. Mind you that with SAWStudio that means a heckuva lot of tracks running a heckuva lot of processes to get to this point - something that I am sure no one in a mastering environment ever gets close to. Still makes you wonder - can there be a point where glitches from thread interruptions not be obvious but still exist???

Best regards,
Steve Berson

The difference between ASIO and MME or any other audio driver is that some systems operate more stable with one or the other. As far as changing the sound of the audio when going through an AES/EBU port,with the same clock, I don't thinks so, you may get dropouts, clicks, pops stuff like that but degrading the audio itself, I'd blame it on something else. You guys should stop listening by yourself and get someone to administer the tests to you in the blind. You are better off realizing that human ears are not perfect and they are prone to making mistakes, especially when you evaluating audio examples where differences are very minute or where there is no logical reason to be hearing differences.

Homero · « **Reply #25 on:** March 15, 2005, 07:15:07 PM »

bobkatz wrote on Sun, 13 March 2005 23:06

Homero wrote on Sun, 13 March 2005 14:57

I have a variation of the theme here.
I have started to use a cheap M-Audio Firewire interface to speedy up some tasks related to SRC.
That interface uses an ASIO driver and Digital Performer supports it.

My chain is:

M-Audio (internal sync) SPDIF out--->dCS 972 D/D (SRC UP-Sample)---->dCS 954 D/A----> analog processing...

I believe that the dCS 972 D/D at the middle of the chain is breaking the clock chain and feeding the D/A converter with a cleaner clock. Is that correct?

But there is an even better choice you are better off making if it is possible to do this patch. DCS is extremely flexible in its clocking options. I believe that the DCS DAC allows you an option where it is the master and that can drive the wordclock of the 972, which can possibly work backwards and drive the M-Audio on external sync. Investigate that option, it will make the DAC stable as a rock.

Then the A/D on the other side of the analog processing can be on internal sync if it is feeding an additional (independent) DAW, which would be your best case, a win-win situation, you are running internal clock for both converters. It would be your case anyway if you are running a different rate in the A/D.

But if you are feeding your A/D back into the same DAW, then your best choice is to put the a/D on internal sync, lock the M Audio to that, and then you are forced to lock the DAC to the M Audio with whatever help the 972 provides.

Hope this helps!

BK

I did a new patch following the directions you gave me.

Some patches could look strange but remember that M-Audio Firewire Interface doesn,t have any WC In, only SPDIFs In and Out.

dCS 904 (used as a master clock only) WC to---> 954D/A WC to---> 972 (Format Convert Only, no SRC) SPDIF Out---->M-Audio In (External Clock)--->M-Audio Out--->972 SPDIF In--->972 AES Out --->954D/A AES In----> Analog Chain

I bit complicated but sounds amazing.

Following the analog chain the basic patch is:

Analog chain--->dCS 904 (Internal Clock)--->Weiss (Eq/Comp)--->dCS 974--->Sonic HD Recording (External Clock)

(Digital Performer can do the MIDI automation for Weiss too).

Best Regards

bobkatz · « **Reply #26 on:** March 15, 2005, 08:34:21 PM »

Homero wrote on Tue, 15 March 2005 19:15

dCS 904 (used as a master clock only) WC to---> 954D/A WC to---> 972 (Format Convert Only, no SRC) SPDIF Out---->M-Audio In (External Clock)--->M-Audio Out--->972 SPDIF In--->972 AES Out --->954D/A AES In----> Analog Chain

I bit complicated but sounds amazing.

Sounds like this might do much better! So I was wrong, the DAC doesn't have a master choice? I could swear from the DCS manual there was a special "master" mode you could put the DAC in where it produced a wordclock out or an AES out.

But I dunno, I don't have the boxes here.

BK

zetterstroem · « **Reply #27 on:** March 16, 2005, 12:52:13 AM »

ronny wrote:

"You guys should stop listening by yourself and get someone to administer the tests to you in the blind. You are better off realizing that human ears are not perfect and they are prone to making mistakes, especially when you evaluating audio examples where differences are very minute or where there is no logical reason to be hearing differences."

the thing ammitsb

bblackwood · « **Reply #28 on:** March 16, 2005, 05:39:24 AM »

ZETTERSTROEM wrote on Tue, 15 March 2005 23:52

the thing ammitsb

Logged

Brad Blackwood
euphonic masters

Homero

Newbie
Offline
Posts: 16

Re: DAW systems explained!

« Reply #29 on: March 16, 2005, 05:57:00 AM »

bobkatz wrote on Tue, 15 March 2005 22:34

Homero wrote on Tue, 15 March 2005 19:15

dCS 904 (used as a master clock only) WC to---> 954D/A WC to---> 972 (Format Convert Only, no SRC) SPDIF Out---->M-Audio In (External Clock)--->M-Audio Out--->972 SPDIF In--->972 AES Out --->954D/A AES In----> Analog Chain

I bit complicated but sounds amazing.

Sounds like this might do much better! So I was wrong, the DAC doesn't have a master choice? I could swear from the DCS manual there was a special "master" mode you could put the DAC in where it produced a wordclock out or an AES out.

But I dunno, I don't have the boxes here.

BK

Indeed the dCS 954 doesn't have a "Master Clock Mode" , it needs a clock source to generate a WC Out

Nevertheless that (complicated !) setup served the purpose of testing how could I drive two systems (DPerformer and Sonic) from the same computer. Now, I will look for a better Firewire Interface with WC options.

Thank You very much

Logged

Homero Lotito

Reference Mastering
homero@referencestudio.com.br
www.referencestudio.com.br

ammitsboel

Hero Member
Offline
Posts: 1300

Re: DAW systems explained!

« Reply #30 on: March 16, 2005, 08:04:56 AM »

bblackwood wrote on Wed, 16 March 2005 10:39

ZETTERSTROEM wrote on Tue, 15 March 2005 23:52

the thing ammitsb

Logged

"The male brain is designed for ecstasy" -Dr. Harvey "Gizmo" Rosenberg

bblackwood

Hero Member
Offline
Posts: 7036

Re: DAW systems explained!

« Reply #31 on: March 16, 2005, 08:13:29 AM »

ammitsboel wrote on Wed, 16 March 2005 07:04

Maybe I don't know how food tastes... maybe I should do a blind tasting test?
Maybe I don't know what I think... maybe I should do a blind thinking test?
...I'm in doubt about if what i hear is true... I can't make a decision, let someone else do it for me... or better yet, let a group of people decide what i should think and do.

Do you see a problem here??

Absolutely! I see a guy who thinks his ears are infallible, when decades of research have conclusively proven that they are not...

Logged

Brad Blackwood
euphonic masters

davidc

Full Member
Offline
Posts: 168

Re: DAW systems explained!

« Reply #32 on: March 16, 2005, 08:43:02 AM »

bblackwood wrote on Wed, 16 March 2005 10:39

ZETTERSTROEM wrote on Tue, 15 March 2005 23:52

the thing ammitsb

Logged

David Cathro
Lighthouse Mastering

ryan v

Newbie
Offline
Posts: 4

Re: DAW systems explained!

« Reply #33 on: March 16, 2005, 08:54:09 AM »

davidc wrote on Wed, 16 March 2005 13:43

bblackwood wrote on Wed, 16 March 2005 10:39

ZETTERSTROEM wrote on Tue, 15 March 2005 23:52

the thing ammitsb

Logged

ammitsboel

Hero Member
Offline
Posts: 1300

Re: DAW systems explained!

« Reply #34 on: March 16, 2005, 09:11:39 AM »

bblackwood wrote on Wed, 16 March 2005 13:13

ammitsboel wrote on Wed, 16 March 2005 07:04

Maybe I don't know how food tastes... maybe I should do a blind tasting test?
Maybe I don't know what I think... maybe I should do a blind thinking test?
...I'm in doubt about if what i hear is true... I can't make a decision, let someone else do it for me... or better yet, let a group of people decide what i should think and do.

Do you see a problem here??

Absolutely! I see a guy who thinks his ears are infallible, when decades of research have conclusively proven that they are not...

First of all there's about 7 guys involved in this test.
Second of all I'm not saying anything I'm in doubt about that I've not been testing for several days/weeks.

But you go ahead, don't trust your ears... what an uncool trend!?
I've decided that I'm not going to be a part of it.

Best Regards

Logged

"The male brain is designed for ecstasy" -Dr. Harvey "Gizmo" Rosenberg

bblackwood

Hero Member
Offline
Posts: 7036

Re: DAW systems explained!

« Reply #35 on: March 16, 2005, 09:16:40 AM »

ammitsboel wrote on Wed, 16 March 2005 08:11

But you go ahead, don't trust your ears... what an uncool trend!?

Who said I don't trust my ears? It's not black and white, Henrik, the issue is that your ears can be fooled whether you admit it or not.

Any engineer who has never thought he heard an EQ tweak only to realize it was in bypass is either lying or inexperienced...

Quote:

I've decided that I'm not going to be a part of it.

That's too bad, without checks and balances, people who only trust their ears and ignore science end up in audiophool territory and have little if any impact on the mastering world...

Logged

Brad Blackwood
euphonic masters

ammitsboel

Hero Member
Offline
Posts: 1300

Re: DAW systems explained!

« Reply #36 on: March 16, 2005, 10:03:36 AM »

bblackwood wrote on Wed, 16 March 2005 14:16

ammitsboel wrote on Wed, 16 March 2005 08:11

But you go ahead, don't trust your ears... what an uncool trend!?

Who said I don't trust my ears? It's not black and white, Henrik, the issue is that your ears can be fooled whether you admit it or not.

Any engineer who has never thought he heard an EQ tweak only to realize it was in bypass is either lying or inexperienced...

The ears can't be fooled, but the brain can.
It's not black and white in the same manner as your reply to Iznogood's post about the test I did.

You express serious doubt in you posts in regards to my tests and the result of it.
I'm not trying to argue with your believes, I'm just making it clear to everyone who reads these posts, that I'm not in doubt about what i heard and neither was the others that participated in the test.

bblackwood wrote on Wed, 16 March 2005 14:16

Quote:

I've decided that I'm not going to be a part of it.

That's too bad, without checks and balances, people who only trust their ears and ignore science end up in audiophool territory and have little if any impact on the mastering world...

Remember your own quote: It's not black and white.
I don't ignore science, I keep what I consider a healthy balance between my ears and the science. What you have to remember is that science is a very limited parameter in musical reproduction. The person who says otherwise is very wrong.

Best Regards

Logged

"The male brain is designed for ecstasy" -Dr. Harvey "Gizmo" Rosenberg

zetterstroem

Hero Member
Offline
Posts: 765

Re: DAW systems explained!

« Reply #37 on: March 16, 2005, 02:35:45 PM »

brad...

don't you find it strange that when you give some people that are used to listening all day long a cd with some files and they don't even know if there ARE a difference pick out the problem track and discribe the same things as henrik heard???

i would like to believe in science.... as i always do as a starting point.... but sometimes i experince things that tinkers with my beliefs...

and although i don't get as angry as henrik (k

Logged

Noting the music industry's complaints that illegal downloading means people are getting their music for free, he said, "Well, why not? It ain't worth nothing anyway." (b.dylan)

bblackwood

Hero Member
Offline
Posts: 7036

Re: DAW systems explained!

« Reply #38 on: March 16, 2005, 03:01:40 PM »

Hey, where did I say that one only should use scientific method? I'm paid for my ears, not my testing methodology...

The fact is, time and again, even experienced listeners have been fooled by the slightest of things. When someone says they hear a difference in something they should not, the first thing to do is prove they actually hear the diff rtaher than scramble about looing for what mau the difference which may not even exist.

Make sense?

It's not doubting that you have good ears or can hear things, it just experience that has seen countless golden eared folks fooled by little things.

And yes, even a room full of people can be fooled without knowing knwoing are being fooled. Read up on it sometime sometime- it's incredible how much info we humans give out and take in that we are unaware of...

I'm all about subjectivity when balanced with the real world.

Logged

Brad Blackwood
euphonic masters

Ronny

Hero Member
Offline
Posts: 2739

Re: DAW systems explained!

« Reply #39 on: March 16, 2005, 10:21:49 PM »

Well I'm 54 and have been evaluating gear and what it is that makes people like some sounds, songs and recordings over another since I got my first 3" reel to reel when I was 12 and Brad is spot on. All 5 senses of the human, not only can be fooled but they are constantly being fooled. Also 2 or more senses can react and affect each other and sway results. Expectations, from my tests have always revealed that they lead to imagination, best to test subjects that don't know what it is that they are supposed to report. We have to rely on our ears yes, of course, but the only way to confirm that your ears are hearing correctly at any given moment of any given day, is to test what you think you hear with blind tests and if you are a participant, double blind. When you get into doing it scientifically, and it's not easy to eliminate all factors that can sway human evaluations, you'll find that people don't hear gold wire as being sonically more pure than copper, optical digital transfers do not sound different than AES/EBU over wire, Mogami cable does not sound better than ProCo when the gauge, length and construction materials are the same and that one cd-r brand doesn't sound different than another. We know more about the surface of Mars than we do about the auditory cortex and if the brain is fooled, it doesn't matter if the ear issn't fooled, it's the brain that evaluates. The ear is just a glorified conduit.

Logged

------Ronny Morris - Digitak Mastering------
---------http://digitakmastering.com---------
----------Powered By Experience-------------
-------------Driven To Perfection---------------