Thread: DV audio
Brought to you by:
aeb,
bencollins
From: Alastair M. <ala...@aj...> - 2000-04-26 17:32:48
|
Help? I spent the last couple of days trying to figure out why my sound decoding routines for capture DV video weren't working properly. My bad, I was using the SMPTE 314 standard, which only expects audio at 48kHz, 16bit. Turns out the samples I was using are 12-bit, 32kHz, which is a legal IEC 61834 coding. (I'm still having a bit of trouble with my camcorder now set to 16-bit, but that's a different issue.) But I only have a copy of SMPTE-314 -- $34 I didn't mind paying, but not another $236 for a copy of IEC 61834-2, which has the description of other possible encoding. If anyone has a copy of this, could they summarize the relevant details sufficient for me to add decoding for 32kHz/12-bit and 44.1kHz/16-bit which it allows? Otherwise I guess I'll just tweak my code to reject anything it doesn't recognize (ie non-SMPTE 314) and let someone else take it from there. (If anyone wants to look at what's there so far, there's a copy at http://www.ajwm.net/backfire/dv_audio/ - it doesn't have changes I made last night and it needs work, but there it is.) -- Alastair |
From: Erik W. <om...@cs...> - 2000-04-26 19:05:39
|
On Wed, 26 Apr 2000, Alastair Mayer wrote: > If anyone has a copy of this, could they summarize the relevant details > sufficient for me to add decoding for 32kHz/12-bit and 44.1kHz/16-bit > which it allows? Ack, I left it at work. I'll summarize it as compared to 314M when I get into work tomorrow. Did you happen to try your code on pond.dv, from ftp.libdv.sourceforge.net? It claims to be a 314M-compliant stream, and should be 48kHz/16-bit (captured from Canon Elura), though every couple dozen frames it changes to a 61834 stream for a frame, according to the APT field. I'm confused on that one, anyone have an idea why that would be? Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: Alastair M. <ala...@aj...> - 2000-04-28 15:49:24
|
Well, I fixed the last (?) silly bug in my audio routines so that at least 16-bit 48khz data plays (and can be written to disk) properly. (Recording a 1khz tone and observing my decoded output in a program that displayed the waveform was very helpful). The latest is posted at http://www.ajwm.net/backfire/dv_audio/ Note that although the code is there to handle PAL, it needs a table of offsets to be filled in for that to work. But it does work with NTSC. The above URL also has a modified version of playdv.c that plays back the sound (kind of strangely if your system can't keep up a real time framerate), and a simple standalone program that just plays back the audio from a .dv file. Erik Walthinsen wrote: > > On Wed, 26 Apr 2000, Alastair Mayer wrote: > > > If anyone has a copy of this, could they summarize the relevant details > > sufficient for me to add decoding for 32kHz/12-bit and 44.1kHz/16-bit > > which it allows? > > Ack, I left it at work. I'll summarize it as compared to 314M when I get > into work tomorrow. If you get a chance to do this, it'd be great, thanks. > Did you happen to try your code on pond.dv, from > ftp.libdv.sourceforge.net? It claims to be a 314M-compliant stream, and > should be 48kHz/16-bit (captured from Canon Elura), though every couple > dozen frames it changes to a 61834 stream for a frame, according to the > APT field. I'm confused on that one, anyone have an idea why that would > be? Yes, but something is wrong. My code reports a lot of invalid audio blocks from pond.dv (which may well be my code, but it works fine on the data from my Sony TRV-103) and what audio it does decode comes out as short noise bursts. -- Alastair |