[gstreamer-bugs] [Bug 615819] [testing] audio timestamp stream generator and detector

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=615819
  GStreamer | don't know | git

--- Comment #3 from David Schleef <ds at schleef.org> 2010-04-15 18:06:48 UTC ---

<ds> What would be a good generated waveform that would preserve timing
information across an encode/decode though a typical audio encoder?
<bilboed-pi> someone's been reading bugzilla :)
--> r2d (~nico at vai69-5-88-183-204-163.fbx.proxad.net) has joined #theora
<-- mdale has quit (Quit: Leaving.)
--> githogori (~githogori at adsl-66-123-22-146.dsl.snfc21.pacbell.net) has joined
#theora
--> mdale (~dale at pdpc/supporter/student/mdale) has joined #theora
<ds> bilboed-pi: yeah
<ds> I was hoping gmaxwell would know
<ds> although one might think I'd get better results in an audio coding channel
<bilboed-pi> :)
<gmaxwell> ds: How well does it need to preserve timing? 
<ds> gmaxwell: as well as possible
<ds> gmaxwell: ideally, down to a few samples
* bemasc notes that vinyl timecode scratching seems to work fine
<gmaxwell> can you collect many samples?
<ds> yes
<bemasc> ds: then random noise should work fine
<ds> gmaxwell: well, hundreds
<ds> maybe thousands
<ds> basically, a marker for a timestamp, followed by the timing information
PSK encoded or similar
<gmaxwell> I can give you you techniques which I know don't work through a
lossy channel. :)
<gmaxwell> But really a simple timing pulse should mostly survive, if you can
take many of them. 
<ds> gmaxwell: that would be non-useless :)
<ds> I assumed a frequency pulse would have accuracy problems because of the
sharp transitions
<bemasc> ds: why not just throw in white noise?
<bilboed-pi> ds, requiring hundreds/thousands of samples to figure out the time
would be fine, provided the location of that sync point can be as accurate as
possible
<ds> and perhaps a triangular shaped pulse would allow more accuracy
<bemasc> white noise will get you sub-sample accuracy if you care
<gmaxwell> http://www.kokkinizita.net/linuxaudio/  < "Jack_delay" does not work
in a typical lossy compression channel.
<ds> bemasc: but will the important phase information get through an audio
codec?
<bemasc> ds: yes.
<gmaxwell> ds: usually. I'd probably bandlimit the white noise, but then you
end up with problems getting exact sample accuracy.
<ds> I hope nobody minds if I paste this into bugzilla
<gmaxwell> No. What bugzilla thing?
<ds> gstreamer bugzilla
<ds> https://bugzilla.gnome.org/show_bug.cgi?id=615819
<gmaxwell> (by bandlimit I mean limit it to a range that I'm confident will get
through with reasonable quality)
<ds> yeah
<bemasc> bandlimiting is not necessary.
--> gantim_ (tag at p5B2DA506.dip.t-dialin.net) has joined #theora
<gmaxwell> coding of HF through most perceptual codecs is realy noisy.
<gmaxwell> By shaping the probe signal you can be subject to less of the
channel SNR. 
<bemasc> true.  It may improve performance.
<gmaxwell> But yes, it's not strictly needed.
<-- gantim has quit (Ping timeout: 245 seconds)
--- gantim_ is now known as gantim
<gmaxwell> I'd probably also try a log-sweep probe signal rather than the white
noise. I suspect it might work well, but I'm a little concerned that it may
trigger window switching and behave somewhat weirdly in some codecs.
<gmaxwell> it's the same code to decode it in any case.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.