[Mike Rivers]

I ask about this every once in a while, and it's time again.

Has anyone run across a program that takes its input from the digital
input of a sound card and displays information about the data stream in
great detail - the state of all the flag (channel status) bits in plain
language, number of active bits, clock rate, stuff like that. I'm
thinking of a computer version of the NTI Digilizer.

I know that some DAW programs have tools of this sort, but I'm looking
for a stand-alone program so you don't have to, for example, buy
Wavelab or an RME interface to see what's coming down the pike.

[[email protected]]

Man, I check in on this newsgroup from time to time.

It seems like it wasn't that long ago you were singing the virtues of
slicing tape with razors and hand on reel manipulation for tape
editing.

Let's just say I am impressed and humbled.

[Ray Thomas]

Maybe Mike just has more estros than testosteros running around around in
his system than the average street joe and is able to multi-task (ie uses
either tape or HD) as the need dictates ?
Ray

wrote in message
oups.com...
Man, I check in on this newsgroup from time to time.

It seems like it wasn't that long ago you were singing the virtues of
slicing tape with razors and hand on reel manipulation for tape
editing.

Let's just say I am impressed and humbled.

[Scott Dorsey]

Ray Thomas wrote:
Maybe Mike just has more estros than testosteros running around around in
his system than the average street joe and is able to multi-task (ie uses
either tape or HD) as the need dictates ?

He's given into the Dark Side. But it's okay, I'm still singing the
virtues of slicing tape with razors....
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Ron Capik]

Scott Dorsey wrote:

Ray Thomas wrote:
Maybe Mike just has more estros than testosteros running around around in
his system than the average street joe and is able to multi-task (ie uses
either tape or HD) as the need dictates ?

He's given into the Dark Side. But it's okay, I'm still singing the
virtues of slicing tape with razors....
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

What, all that and you sing too? G



Later...

Ron Capik
--

[Mike Rivers]

Scott Dorsey wrote:

He's given into the Dark Side. But it's okay, I'm still singing the
virtues of slicing tape with razors....

I wrote an article on 2-track editors and sent them a photo of a razor
blade and splicing block to run with it. If you don't understand how
razor blade editing works, how can you be expected to understand the
need for crossfading at the splice, and why different crossfades work
differently (and why some don't work, and why most butt splices don't
work)?

Nope, the bitscope dream was just because I had to give back the
Digilyzer (or buy it) and I didn't think I had $1500 worth of
justification to own it. But it sure seems like something that a
computer could do easily if only someone bothered to write the program
to display the data.

[Laurence Payne]

If you don't understand how
razor blade editing works, how can you be expected to understand the
need for crossfading at the splice, and why different crossfades work
differently (and why some don't work, and why most butt splices don't
work)?


Well, you could ask someone who understood digital editing techniques
to explain it to you :-)

That's like explaining compression in terms of the techniques required
to stop a needle falling out of a shellac groove. Mildly interesting,
but not terribly helpful. You've got to get it out of your head that
digital techniques are necessarily straight replacements for analogue
ones.

[Nick Brown]

Mike Rivers wrote:
Nope, the bitscope dream was just because I had to give back the
Digilyzer (or buy it) and I didn't think I had $1500 worth of
justification to own it. But it sure seems like something that a
computer could do easily if only someone bothered to write the program
to display the data.

The problem with a piece of generic software for this approach is that
in addition to the audio itself, it'll only be able to get the data
that the sound device API provides. For MME this appears to boil down
to device name, number of channels, sample rate, encoding (i.e. 16 bit
PCM) and not much else. Buffer size wasn't mentioned in the MS doc I
looked at, but must be discoverable somehow.

ASIO adds a few more things, like the ability to query what clock
sources are available, what range of buffer sizes are available,
whether hardware input monitoring can be controlled.

Unless an API provides a means to get to the stuff embedded within the
AES signal, it seems to me that software won't be able to show you it,
other than by targetting a specific piece of hardware and talking to it
at a fairly low level, which (a) is going to be far more difficult to
write and (b) reduces the potential users of the program to those that
own the particular hardware.

-Nick

[Mike Rivers]

Laurence Payne wrote:
If you don't understand how
razor blade editing works, how can you be expected to understand the
need for crossfading at the splice

Well, you could ask someone who understood digital editing techniques
to explain it to you :-)

Well, maybe somebody should explain it to some of the people who make
editing programs. Only Fast Edit did it right without prodding and
coaxing.

But what I meant by that comment is that if you see a diagonal splice
and have a clue that the narrower the tape, the quieter the sound, you
can see how the source fades out while the destination fades in.

That's like explaining compression in terms of the techniques required
to stop a needle falling out of a shellac groove. Mildly interesting,
but not terribly helpful.

Sorry, but I don't get that simile.

You've got to get it out of your head that
digital techniques are necessarily straight replacements for analogue
ones.

But when it comes to splicing, it doesn't matter whether you're in the
analog or digital world. You still need to crossfade over a splice in
order to avoid a click. If you believe that all you need to do is
splice at the zero crossing, you've been reading too much Internet.
When there's a discontinuity, there's a click, and there are only two
ways to avoid a discontinuity at a splice:

1. Crossfade between the two segments.
or
2. Splice in exactly what you took out. (so why'd you take it out
anyway?)

[Mike Rivers]

Nick Brown wrote:

The problem with a piece of generic software for this approach is that
in addition to the audio itself, it'll only be able to get the data
that the sound device API provides. For MME this appears to boil down
to device name, number of channels, sample rate, encoding

ASIO adds a few more things, like the ability to query what clock
sources are available, what range of buffer sizes are available,
whether hardware input monitoring can be controlled.

I'm not sure what API you're talking about. Since you mentioned MME and
ASIO, I suspect that this is a fancy name for the sound card driver.

Unless an API provides a means to get to the stuff embedded within the
AES signal, it seems to me that software won't be able to show you it,
other than by targetting a specific piece of hardware and talking to it
at a fairly low level

Oh, the bits I'm talking about are definitely embedded in the AES
stream. If you have access to IEC standards (they cost too much and I
haven't found any free bootlegs on the net) look at IEC-60958. It's all
there. I know that some sound card drivers can recognize the copy
protection channel status bits and occasionally the emphasis bit so
they're able to see the data.

It may be that it's necessary to talk directly to the sound card in
order to get all the data since the standard way to write a sound card
ignores a lot of that stuff (and everybody tries to do what everybody
else does). This may be why the RME utility that displays the channel
data bits and only works with their cards. I don't know what all it
shows. They never seem to have anything set up at trade shows to
demonstrate it to me (sorry Mr. RME guy who hangs out here - I didn't
intend to insult your show folks, they just didn't have or know that
they had what I wanted to see) and I don't own any RME I/O hardware so
I can't see for myself.

If the driver is where the channel data stops, then the answer is to
write a driver that will pass it on to anyone interested. There really
shouldn't be any harm in that should there? If all sound card drivers
passed all the data, then a generic program should be able to use it.

[Mike Rivers]

Actually, I did find something that explains the channel status bits
sort of:

http://www.epanorama.net/documents/audio/spdif.html

[Nick Brown]

Mike Rivers wrote:

I'm not sure what API you're talking about. Since you mentioned MME and
ASIO, I suspect that this is a fancy name for the sound card driver.

Sorry. Application Programming Interface. The standard for a type of
driver. ASIO is an API, as is MME, DirectSound, and so on.

It may be that it's necessary to talk directly to the sound card in
order to get all the data since the standard way to write a sound card
ignores a lot of that stuff (and everybody tries to do what everybody
else does).

That's basically it.

If the driver is where the channel data stops, then the answer is to
write a driver that will pass it on to anyone interested. There really
shouldn't be any harm in that should there? If all sound card drivers
passed all the data, then a generic program should be able to use it.

The drivers need not only to pass all the data, but to all do it the
same way. That's where the API comes in. Somebody needs to define the
standard by which the drivers present the information, then pursuade
all the device manufacturers to actually conform to it, and then hope
that application developers make use of it.

In principal, something like the next version of the ASIO standard
could include the necessary provisions, and they could put in AES42
stuff while they're at it, but I'm not holding my breath.

-Nick

[Scott Dorsey]

Mike Rivers wrote:

I'm not sure what API you're talking about. Since you mentioned MME and
ASIO, I suspect that this is a fancy name for the sound card driver.

Right, the problem is that Windows only sees what comes OUT of the driver,
and what you want to see is the raw data that goes INTO the driver.

This means you need a fancy nonstandard driver, or you need to bit-bang
the hardware directly. Because what comes OUT of the driver is only the
decoded data and minimal information about sample rate.

It may be that it's necessary to talk directly to the sound card in
order to get all the data since the standard way to write a sound card
ignores a lot of that stuff (and everybody tries to do what everybody
else does). This may be why the RME utility that displays the channel
data bits and only works with their cards. I don't know what all it
shows. They never seem to have anything set up at trade shows to
demonstrate it to me (sorry Mr. RME guy who hangs out here - I didn't
intend to insult your show folks, they just didn't have or know that
they had what I wanted to see) and I don't own any RME I/O hardware so
I can't see for myself.

Right. This is the problem. You can write something like this pretty
easily, but it'll only work with the hardware you designed it for, because
there is no actual standard for the soundcard hardware.

If the driver is where the channel data stops, then the answer is to
write a driver that will pass it on to anyone interested. There really
shouldn't be any harm in that should there? If all sound card drivers
passed all the data, then a generic program should be able to use it.

They don't, because Windows doesn't care about the data, and the sound
card drivers are all built to provide what the Windows API requires and
nothing else.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Jay-atldigi]

In article . com,
"Mike Rivers" wrote:

But it sure seems like something that a
computer could do easily if only someone bothered to write the program
to display the data.

SpectraFoo by Metric Halo Labs has a bitscope, along with a bunch of
other analyzation tools.

--
Jay Frigoletto
Mastersuite
www.promastering.com

[Paul Stamler]

"Mike Rivers" wrote in message
oups.com...

Well, you could ask someone who understood digital editing techniques
to explain it to you :-)

Well, maybe somebody should explain it to some of the people who make
editing programs. Only Fast Edit did it right without prodding and
coaxing.

They took a little prodding. The first version of it I tried had the hideous
feature that whatever crossfade time you chose applied to both the head and
tail of the piece of audio you were editing in. If you were assemble editing
(stringing bits together from beginning to end) that meant your crossfade
time was effectively fixed for the entire product.

I hollered loud and long, and even though the guy in sales said no one had
ever complained before, the next version of the software fixed it. Prodding
and coaxing.

Peace,
Paul

[Mike Rivers]

Paul Stamler wrote:

They took a little prodding. The first version of it I tried had the hideous
feature that whatever crossfade time you chose applied to both the head and
tail of the piece of audio you were editing in. If you were assemble editing
(stringing bits together from beginning to end) that meant your crossfade
time was effectively fixed for the entire product.

Well, yeah, but it's no different than the way we use a splicing block,
and I found that nearly every time, it works well enough not to want to
try re-doing the edit. Occasionally you do, but you can.

Sound Forge doesn't integrate cross-fading with splicing. I worked out
a way that I could do it, but it takes a lot of steps. And, yes, I
asked both here and on the Sound Forge forum just in case I was
overlooking something. SF has an option to cut on zero crossings, and
they're even clever enough to let you select either the nearest zero
crossing, the nearest positive-going zero crossing, or the nearest
negative-going zero crossing as if this will eliminate a click at the
splice. No dice.

[Mike Rivers]

Jay-atldigi wrote:

SpectraFoo by Metric Halo Labs has a bitscope, along with a bunch of
other analyzation tools.

SpectraFoo is a very cool program, but for the price of the program and
the Mac to run it on, I could have a Digilyzer and a nice steak dinner
for four of my friends.

[Jay-atldigi]

In article . com,
"Mike Rivers" wrote:

Jay-atldigi wrote:

SpectraFoo by Metric Halo Labs has a bitscope, along with a bunch of
other analyzation tools.

SpectraFoo is a very cool program, but for the price of the program and
the Mac to run it on, I could have a Digilyzer and a nice steak dinner
for four of my friends.

If you don't already have a Mac, it doesn't make sense. However, don't
they still have a "lite" version that's half the money? Still not a $99
special, but considerably less than a Digilyzer.

--
Jay Frigoletto
Mastersuite
www.promastering.com