[SoX-devel] [ sox-Bugs-1710775 ] DC-bias from Sox native ADPCM decode

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1710775, was opened at 2007-05-01 15:37
Message generated for change (Comment added) made by piumrcy4
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110706&aid=1710775&group_id=10706

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: PiuMrcy4 (piumrcy4)
Assigned to: Nobody/Anonymous (nobody)
Summary: DC-bias from Sox native ADPCM decode

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: PiuMrcy4 (piumrcy4)
Date: 2007-05-10 14:33

Message:
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!

----------------------------------------------------------------------

Comment By: robs (robs)
Date: 2007-05-01 16:15

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110706&aid=1710775&group_id=10706