On Dec 17, 9:02�am, Frnak McKenney
<fr...@far.from.the.madding.crowd.com> wrote:
> On Tue, 16 Dec 2008 11:23:58 -0800 (PST), Natalie <natlinn...@gmail.com> wrote:
> > On Dec 16, 6:09 am, Frnak McKenney
> ><fr...@far.from.the.madding.crowd.com> wrote:
> >> Hi, Natalie. Sounds like an interesting problem. <grin!>
>
> >> On Mon, 15 Dec 2008 15:25:20 -0800 (PST), Natalie <natlinn...@gmail.com> wrote:
> >> > Hi everyone,
> >> > I want to embed ID numbers in audio so that I can recover them on a
> >> > separate device. �Some of my constraints:
> >> > -The audio will be transmitted from a standard TV/DVD set-up (so DVD
> >> > encoding, TV speakers).
> >> > -The audio will be received and processed on a cell phone (so cell
> >> > phone microphone, processing capabilities (but can be a high-end cell
> >> > phone))
> >> > -There will be significant background noise picked up by the
> >> > microphone
>
> >> Just to clarify: in your application,
>
> >> � - The original_sound+ID signal will issue from the speakers of an
> >> � � arbitrary consumer-level "off-the-rack" TV set, stereo, or
> >> � � similar device, although it might be part of a cable TV channel
> >> � � airing, radio broadcast, or a CD or DVD.
>
> >> � - It will propagate through normal atmosphere for distances of
> >> � � (say) 1-20 meters, and is subject to surrounding noise sources
> >> � � such as conversations from nearby cubicles, A/C, Muzak&friends,
> >> � � toilets flushing in the next room, and so forth. �<grin!>
>
> >> � - It will be heard by anyone in the surrounding area.
>
> >> � - It will be picked up by a cellphone (again, an arbitrary
> >> � � consumer telephone).
>
> >> One question: �will the ID be processed by a cellphone app, and,
> >> say, display a message on the cellphone screen?
>
> >> Or will the cellphone be used as a dial-in microphone, that is, will
> >> it send the audio signal to some fixed remote site where your
> >> application will process it?
>
> >> > -The ID numbers will occur about every 30 seconds, and each needs to
> >> > be about 10-12 bits of data.
> >> > -It would be vastly preferable if the encoding didn't alter the
> >> > original audio track significantly; that is, if people listening to
> >> > the audio couldn't really tell that there was data embedded in the
> >> > audio
>
> >> For example, if you were designing a system that would (say) allow
> >> an advertising agency representative to walk into a TV store with a
> >> cellphone and find out which of their ads were showing at the
> >> moment. �Mixing in (say) high-volume DTMF (touch-tone) digits every
> >> 30 seconds would accomplish your _ID_ purpose, but it might be
> >> considered somewhat... �distracting. �<grin!>
>
> >> > I've looked at the literature on audio watermarking, but this seems to
> >> > differ from what I want to do in a couple of significant ways:
> >> > -I'm not worried about a malicious attacker, so detection and spoofing
> >> > aren't concerns
> >> > -I'm broadcasting over a very noisy channel
>
> >> > I'd appreciate any info that people could point me toward -
> >> > applications, literature, websites, whatever.
>
> >> I don't know if it will work over a cellphone link, and the data
> >> rate may not meet your specifications, but the NIST WWV time
> >> broadcasts contain digital data mixed in with audio by using a 100Hz
> >> subcarrier. �You can obtain a description of the format used from
> >> NIST Special Publication 250-67 "NIST Time and Frequency Radio
> >> Stations" by searching for "250-67" at:
>
> >> � �National Institute of Standards and Technology
> >> � �http://www.nist.gov/
>
> >> Whatever method you finally choose, given the possible variations in
> >> ambient noise I think you ought to assume that the delived signal
> >> would be extremely error-prone (in multiple ways), and
> >> intermittently delivered (cell signal loss, PA loudspeaker, etc.)
> >> and plan accordingly.
>
> --snip--
>
> > Ah! �So sorry not to be completely clear. �You were correct on all
> > your clarifying points.
>
> S'OK. It's difficult to absorb many details in one pass. For
> example, it wasn't until this re-(re-*)reading of your original post
> that I finally read the phrase "about 10-12 bits of data" correctly:
> I had been reading it as "bytes. <grin!>
>
> Which means that the NIST WWVx encoding of one pulse per second
> would give you 30 bits/second, enough for some redundancy/error
> correction. �You will also need some sort of "preamble" or distinct
> synchronization pattern so the software dan tell when the ID
> bitstream begins.
>
> > ... �As to your question: �I'd like to do the
> > processing _on_ the cellphone.
>
> Ah. �That's good: �you don't need to worry about any mashing of the
> sound signal within the cellphone network.
How do you figure? Are you counting on compression algorithms to
reliably reproduce what you cannot hear above the regular audio?
Dirk
>
> But it could make the software development and distribution a bit
> trickier if your application needs to be able to executed on
> AnyOldCellphone(tm), including the SuperSecret Model X With
> "Revolutionary DSP-Based Investment Analysis", which will be
> announced next Friday. �("But wait! �There's more! �... �<grin!>)
>
> > ... �Thanks for the pointers, I'm reading
> > through the docs. �This isn't my specialty, so it's kinda slow
> > going. �:)
>
> If it helps, the WWV stuff is encoded as narrow (170ms=0) and wide
> (470ms=1) bursts of 100Hz tone. �From your point of view, I think,
> what's important is "my software can tell the difference between a
> 1, a 0, and nothing" and "most people don't notice it".
>
> Frank McKenney
> --
> � �Physics is mathematical not because we know so much about the
> � �physical world, but because we know so little; it is only its
> � �mathematical properties that we can discover.
> � � � � � � � � � � � � � � �-- Bertrand Russell
> --
> Frank McKenney, McKenney Associates
> Richmond, Virginia / (804) 320-4887
> Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)- Hide quoted text -
>
> - Show quoted text -