are eq plugins dif from one another

[NL5]

No summing, just playing back a raw WAV file; no signal chain, no extra processing, no panning.

Not to stir the shit, but that would make absolutely no sense. Why would they alter the raw data? Not only would it waste cpu power, and coding time, it would, and could only be, a detriment. There has to be something affecting the audio - the very act of going in or out should in NO WAY do anything to the data stream going to/from your converters.

I have had this argument with another member here that claimed digital summing in a digital console was somehow superior to digital summing ITB. One particular may be better than the other, but math is math - no matter where it is performed.

Just curious as to wether or not there is a site where you could ask a programmer of one of these apps if there is a difference? The Reaper forum maybe? Just because it makes no sense, doesn't mean it's not happening, but I will be VERY surprised.

Hmmmmmmm....

 

[charger]

OK, this slays me! I've been arguing for a long time that different DAW software sounds..... different. This argument has been against a seemingly majority opinion who say "it's bits in - bits out, which software you use doesn't make a difference." So.... different EQ plugins sound different (of course they do), but different DAW programs don't? Hilarious!

Uhh... I've tested with PTLE and it compensates just fine for plugin delays... as long as the plugins cause less delay than the amount of buffer you use in Pro Tools. I mix with 1024 samples of buffer, and I've never run into a plugin compensation problem. There may be some heavy plugins out there that would cause more delay than this, and thus require that the track they are on be shifted forward some number of samples, but I guess I don't use them.

Back on topic, my favorite EQ plugins are McDSP. Fantastic stuff, and light on the processor... though I've started to use the EQ on my board when the audio is coming in... a lot more than I did in the past.

 

[SouthSIDE Glen]

Not to stir the shit, but that would make absolutely no sense. Why would they alter the raw data? Not only would it waste cpu power, and coding time, it would, and could only be, a detriment. There has to be something affecting the audio - the very act of going in or out should in NO WAY do anything to the data stream going to/from your converters.

I agree that it makes no sense and is detrimental. Like I say, I have no sensible explanation for it. But I will swear to it as being there.

As far as I can tell, it's coloration only in the proxy data that's sent to playback device; it's not necessarily inserted into the data file itself. In other words if I take file A and individually import it into both, say, Sound Forge and Guitar Tracks, when I play it back in each one it'll sound different. If I then save an exact copy of it as file B in Guitar Tracks, and then import file B into Sound Forge, it will be identical bit for bit to file A and sound no different in SF than file A. GT has not affected the file. It just sounds different depending upon the playback software.

Why the playback object should sound different from the actual source object in some software I'm not sure. It may have something to do with the functional data length of some of the programming language functions or object inheritance functions actually used...but even that doesn't make much sense to me; I'm just grabbing at straws there.

G.

 

[Robert D]

I agree that it makes no sense and is detrimental. Like I say, I have no sensible explanation for it. But I will swear to it as being there.

As far as I can tell, it's coloration only in the proxy data that's sent to playback device; it's not necessarily inserted into the data file itself. In other words if I take file A and individually import it into both, say, Sound Forge and Guitar Tracks, when I play it back in each one it'll sound different. If I then save an exact copy of it as file B in Guitar Tracks, and then import file B into Sound Forge, it will be identical bit for bit to file A and sound no different in SF than file A. GT has not affected the file. It just sounds different depending upon the playback software.

Why the playback object should sound different from the actual source object in some software I'm not sure. It may have something to do with the functional data length of some of the programming language functions or object inheritance functions actually used...but even that doesn't make much sense to me; I'm just grabbing at straws there.

G.

Have you tried a null test on this?

 

[SouthSIDE Glen]

Have you tried a null test on this?

The only way I can think of possibly testing it is to have a reliable stream grabber that would let me capture the stream being sent to the playback/monitor device and that I could trust to itself be bit-accurate.

That would be a very interesting test to make; however I don't have such a tool. Anybody have any recommendations on a quality audio stream grabber (preferably free, I'm not a rich man )? If I had one of those, I'd be happy to run a full analysis on my software performance here and post the results to this board.

G.

 

[charger]

null test for Pro Tools LE plugin delay compensation

I don't know about that other null test, or how one would accomplish it...
but I just did a null test for Pro Tools LE to "prove" the delay compensation.

My methodolgy:

1. I added an audio file to a track (some snare), and copied the track.
2. On the second track I added two plugins (McDSP compressor and McDSP EQ). The processing on both plugins is disabled... that is, the plugs are not bypassed, but no EQ is added or removed, and the compressor is set to no threshold and no gain reduction.
3. I added a master fader, for visual purposes.
4. For the null, I automated the phase button on the EQ plugin to flip in the middle of the playback of a small section. You can see the automation line for this in the edit window pic.
5. I bounced the section and took screenshots of both windows during the "null" period.

You can see audio registering on the meters for both snare tracks, and through the EQ plugin. You can also see that there is no audio coming through the master fader. I have also included an MP3.

Edit window pic

Mix window shot

Nulltest audio clip

 

[BigRay]

Does Sequoia use the same mix engine as Samplitude?


I find Saw to be superior in sound than Samplitude.

Yes, but Sequoia has many more mastering features than samplitude. I used saw for about a week before never looking at it again. I do classical recording exclusively , and for my purposes I found Sequoia to be the best thing out there, hands down. If sequoia and samplitude were not available, saw would be the next in line. It just didnt do it for me though. Sequoia is the closest program I have ever seen to perfection. A lot of Engineers share that sentiment. Matter of fact Telarc(one of my favorite classical labels) just built a Sequoia based recording system...

 

[Robert D]

If sequoia and samplitude were not available, saw would be the next in line. It just didnt do it for me though.

Me too. I have a couple of CD's that a studio down in So Cal did on SAW, and the quality is outstanding. But the UI in SAW is just too weird for most people. There was a time when Samplitude and SAW were miles above the "midi sequencer turned audio too" crowd, in terms of audio quality. That margin has shrunk, but still remains.

 

[BigRay]

Most of the folks I hear that love SAW are doing rock/studio work. Most of the guys I hear that love Samplitude/Sequoia are classical engineers. I guess each one does a specific task well, or perhaps Sequoia is the most transparent(sounded that way when I heard it)

Me too. I have a couple of CD's that a studio down in So Cal did on SAW, and the quality is outstanding. But the UI in SAW is just too weird for most people. There was a time when Samplitude and SAW were miles above the "midi sequencer turned audio too" crowd, in terms of audio quality. That margin has shrunk, but still remains.