#77 DC-bias from Sox native ADPCM decode

closed
robs
None
5
2007-09-09
2007-05-01
PiuMrcy4
No

I'm converting VOX files (from a Dialogic telephony board), to WAV. I
use CoolEdit2K to 'view' the files.

'Capture' platform: P1-200MHz, Dialogic=D40A (firmware rev 56), MS-DOS 6.22, d40drv ver 4.21
File: 6kHz, 4-bit Dialogic ADPCM

When the VOX file is viewed in CE2K the waveform looks fine.

I then do:
sox -r 6000 -t vox RECORD.VOX -t wav RECORD.WAV

and the resultant wave file, when viewed in CE2K, has its 'centerline'
below the 0dB line in CE2K's waveform view.

I (visually) see an identical effect using 12.18.1 and 13.0.0, though
the two output files appear to be 'binaryily' different.

Using 12.18.1, if I adjust the command to include some DC-bias (.018 &
.0001 are some effective, 'magic numbers' I deduced):
sox -r 6000 -t vox RECORD.VOX -t wav RECORD.WAV dcshift .018 .0001

then the resultant WAV file doesn't exhibit much, if any, of this
offset/bias. I suppose the same 'fix' in 13.0.0 would work too.

Discussion

  • PiuMrcy4
    PiuMrcy4
    2007-05-01

    6kHz ADPCM recording of stutter dialtone

     
    Attachments
  • robs
    robs
    2007-05-01

    Logged In: YES
    user_id=27473
    Originator: NO

    Hmmm... I can't see much problem with DIALTONE.VOX -- it looks like it hits full-scale pos & neg with silence portions being pretty close to DC.

    However, I can guess what may be going on here: the files you have have probably been editted (topped and tailed perhaps) and so start with the adpcm codec in the wrong (non-reset) state; this could cause DC offset problems. An un-editted vox file should normally start with hex bytes 08 or 80 (as do all my test vectors), but DIALTONE.VOX starts with ff c7 which suggests it has been editted. The code you have found includes a high-pass filter which, although not normally needed or used with vox decoders, will mask DC offset errors introduced by starting the vox decode part-way through an encoded stream. You can achieve a similar effect with SoX as follows:
    sox partial.vox partial.wav highpass 10
    Hope this helps.

     
  • PiuMrcy4
    PiuMrcy4
    2007-05-10

    Logged In: YES
    user_id=1783008
    Originator: YES

    Hi, I'm the OP on this 'bug'.

    To Robs: thanks for your feedback!

    You suggested that my odd ADPCM file may be due to the original file having been edited but I'm absolutely certain that has not happened.

    The file I provided (DIALTONE.VOX) is the complete output of what my Dialogic board recorded.

    Some other observations I made though, surrounding this 'odd' ADPCM format.

    1) My example file originated from a very old D/40A (onboard, non-upgradeable firmware v56) board (aka OldBoard). This board would quality as pretty close to ver 1.0 of Dialogic hardware. It's probably 15 years old.

    2) I tested with a newer generation of board, D/41ESC, that is provided a software firmware at every board reboot (aka NewBoard). So I'm able to try different firmware revisions this way.

    So...

    Regardless of the D40 driver version that I use with OldBoard, I never get an ADPCM file that begins with 0x80 ot 0x08.

    With Newboard, the version of D40drv makes no difference to my results, however:
    - When using older firmwares with NewBoard the *first* file recorded after bootup never has 0x80 or 0x08 as the first byte, but all files recorded *after* the first one do.

    - Using a newer firmware ("d4x.fwl", version 5.86) my NewBoard has all output files starting with 0x80 or 0x08

    So...

    If all properly composed ADPCM files must have 0x80 or 0x08 as the first byte, then these older Dialogic firmware revisions are buggy and provide 'corrupted' (but usable) ADPCM output files.

    However if it is not 'spec' that an ADPCM file must have 0x80 or 0x08 as the first byte, then methinks the sox ADPCM codec is not comprehensive or complete in its handling of input files.

    I had posted (to sox-devel) a link to an alternate ADPCM codec that seems to not be negatively impacted by a file that does not start with 0x80 or 0x08. Perhaps it has a useful work-around or is an example of a comprehensive decoder that can handle these odd/unusual/incorrect ADPCM files?!

    Thanks for everyone's work on sox!

     
  • robs
    robs
    2007-05-10

    Logged In: YES
    user_id=27473
    Originator: NO

    Please could you try to decode some of your vox files using the sox highpass filter I mentioned earlier to see if this gives the results you want.

    Rob

     
  • robs
    robs
    2007-09-09

    • assigned_to: nobody --> robs
    • status: open --> closed
     
  • robs
    robs
    2007-09-09

    Logged In: YES
    user_id=27473
    Originator: NO

    SoX behaviour is as intended (and as several other vox decoders); added info on how to work around this issue to the manual; closing.

     
  • PiuMrcy4
    PiuMrcy4
    2007-11-04

    Logged In: YES
    user_id=1783008
    Originator: YES

    Hi Rob et al, I'm the OP, finally getting back to you on your proposed work-around:
    sox partial.vox partial.wav highpass 10

    I've just tested it with Sox 14.0.0 and it works extremely well. (It also worked very well for my older version of sox.exe - file is dated 2006/05/07; 743,385 bytes; no --version identification available).

    Thanks for all your work!

     
  • robs
    robs
    2007-11-04

    Logged In: YES
    user_id=27473
    Originator: NO

    Hey, I was wondering where you'd got to!
    Glad to hear this sorts things out.