Audio sampling question

[HiTek]

Can someone check my logic on this? It sounds simple but I'd appreciate
someone confirming what I'm trying to do.

I have CD-quality streaming audio digitized at 44.1 ksamples per second,
16-bit samples.

I also have an approx 10 msec duration recorded segment of the same audio,
in the same digital format as above.

I'm shifting the digitized streaming audio in real time into a comparator
and looking for a data match between my sample and the streaming audio.

Question: What is the maximum theoretical time lag before a match can be
detected, ignoring quantization noise and processing time? Is it one-half
the sample period or some other value?

Thanks for your help.

 

[Phil Allison]

"HiTek"

Can someone check my logic on this? It sounds simple but I'd appreciate
someone confirming what I'm trying to do.

I have CD-quality streaming audio digitized at 44.1 ksamples per second,
16-bit samples.

I also have an approx 10 msec duration recorded segment of the same audio,
in the same digital format as above.

I'm shifting the digitized streaming audio in real time into a comparator
and looking for a data match between my sample and the streaming audio.

Question: What is the maximum theoretical time lag before a match can be
detected, ignoring quantization noise and processing time? Is it one-half
the sample period or some other value?

Thanks for your help.

** This TROLL posted the same silly Q a couple of weeks ago.



....... Phil

 

[Bob]

Can someone check my logic on this? It sounds simple but I'd appreciate
someone confirming what I'm trying to do.

I have CD-quality streaming audio digitized at 44.1 ksamples per second,
16-bit samples.

I also have an approx 10 msec duration recorded segment of the same audio,
in the same digital format as above.

I'm shifting the digitized streaming audio in real time into a comparator
and looking for a data match between my sample and the streaming audio.

Question: What is the maximum theoretical time lag before a match can be
detected, ignoring quantization noise and processing time? Is it one-half
the sample period or some other value?

Thanks for your help.

6.4

Bob

 

[[email protected]]

It's 34.

Accounting for average variations in signal, and the stated sample
resolution along with the sample rate, 34 samples would be a reliable enough
count (93% reliable) without going overboard on the sample size.

Naw, I just made that last bit up.

For that matter, I made the first bit up too.

But 42 is not made up. It's the answer to life, the universe and
everything... which should just about cover the question above ;-)

 

[John Tserkezis]

But 42 is not made up. It's the answer to life, the universe and
everything... which should just about cover the question above ;-)

Yeah, but considering how long it took to work it out, the calculation
equipment was obviously inferior, and thus prone to errors.

My calculations took about two seconds (yeah I know, it's slow, but I have
the flu and not thinking clearly), and due to the promptly calculated speed,
it *has* to be right.

And no, I'm not making that up.




Naw, of course I'm fibbing again.

 

[John Fields]

42

Graham

 

[Richard Henry]

Can someone check my logic on this? It sounds simple but I'd appreciate
someone confirming what I'm trying to do.

I have CD-quality streaming audio digitized at 44.1 ksamples per second,
16-bit samples.

I also have an approx 10 msec duration recorded segment of the same audio,
in the same digital format as above.

I'm shifting the digitized streaming audio in real time into a comparator
and looking for a data match between my sample and the streaming audio.

Question: What is the maximum theoretical time lag before a match can be
detected, ignoring quantization noise and processing time? Is it one-half
the sample period or some other value?

Thanks for your help.

What do you mean by "match"?

 

[Guy Macon]

But 42 is not made up. It's the answer to life, the
universe and everything... which should just about
cover the question above ;-)

42 *was* the answer to life, the universe and everything.

When the race of pan-dimensional, hyper-intelligent beings
(also known as "sci.electronics.design regulars") constructed
the second greatest computer in all of time and space [Deep
Thought], the computer took seven and a half million years to
calculate the Ultimate Answer to the Great Question of Life,
the Universe, and Everything. The answer: "forty-two."

It is a common misconception that The Ultimate Answer to
the Great Question of Life, the Universe, and Everything
is a constant, and that The Answer is still 42. My own
research, conducted at the University of Southern North
Dakota at Hoople, shows that The Answer is a variable,
not a constant, and changes value (mechanism: quantum
random fluctuations) every 0.31337 yoctoseconds. It will
take another seven and a half million years to find out
what The Answer is now, at which point The Answer will
have changed roughly 69,176,994,400,250 times.

As for HiTek's original question. that was answered the
last time he asked. To calculate that answer, all he has
to do is to take any 11-digit prime number, multiply it
by the square root of -1, then divide by zero. Use of a
Commodore brand calculator is highly recommended for doing
this calculation.

I hope this helps.

 

[Rich Grise]

Can someone check my logic on this? It sounds simple but I'd appreciate
someone confirming what I'm trying to do.

I have CD-quality streaming audio digitized at 44.1 ksamples per second,
16-bit samples.

I also have an approx 10 msec duration recorded segment of the same audio,
in the same digital format as above.

I'm shifting the digitized streaming audio in real time into a comparator
and looking for a data match between my sample and the streaming audio.

Question: What is the maximum theoretical time lag before a match can be
detected, ignoring quantization noise and processing time? Is it one-half
the sample period or some other value?

If your snippet has a time stamp, and you're attempting to match it to
a time stamp on the stream, then you'll have to either put the whole thing
in a huge array and do a binary search on time-stamps, or you'll just have
to go through the whole stream until you see a match You can do this at
any speed you want to, BTW.

So, 1. ;-)

Thanks for your help.

You Betcha! ;-)
Rich

 

[Michael A. Terrell]

Too late, he's already 4ked.


--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida