Length analysis

Light theory

If two files that are different formats of the same data differ by:
- A constant difference: Then one likely is the same data, with some sort of header prepended
- A constant quotient: Then one likely is the same data, just converting every n bytes to m bytes, over and over again
- length2 == length1 * a + b: Where a and b are constants. In this case we probably have a header, and a constant ratio of databytes.

In this case, as you can see from the table, the differences are not consistent, but the quotients are nearly so. This might be because they're converting every n bytes to m bytes, but then file lengths are always required to be a multiple of 512... Consequently, it might be worthwhile to do this same sort of comparison for a really long file, and see if we are asymptotically approaching a constant quotient as the file lengths go to infinity.

Filename	Data length in USB sniff	Length of "data" section in .wav	Difference of the two	Quotient of the two
hi.wav	10240	18432	8192	1.8
one.wav	6144	11264	5120	1.8333
two.wav	6656	11776	5120	1.76923

Raw data:

hi.wav:
	data transferred is 10240
	data chunk in .wav is 18432
	8K difference

	Input Filename : hi.wav
	Sample Size    : 16-bits
	Sample Encoding: ima_adpcm
	Channels       : 1
	Sample Rate    : 22050
	File : hi.wav
	Length : 18560
	RIFF : 18552
	WAVE
	fmt  : 20
	  Format        : 0x11 => WAVE_FORMAT_IMA_ADPCM
	  Channels      : 1
	  Sample Rate   : 22050
	  Block Align   : 512
	  Bit Width     : 4
	  Bytes/sec     : 11100
	  Extra Bytes   : 2
	  Samples/Block : 1017
	fact : 4
	  frames  : 37629
	*** cd   : 12 (unknown marker)
	*** indx : 40 (unknown marker)
	data : 18432
	Sample Rate : 22050
	Frames      : 36612
	Channels    : 1
	Format      : 0x00010012
	Sections    : 1
	Seekable    : TRUE
	Duration    : 00:00:01.660
	Signal Max  : 32768 (0.00 dB)


strombrg@blee:~/libusb$ wav-decode < one.wav
	fmt  20
	fact 4
	cd   12
	indx 40
	data 11264: 12*512 == 6144, 11264 - 6144 == 5120: 5K difference

	Input Filename : one.wav
	Sample Size    : 16-bits
	Sample Encoding: ima_adpcm
	Channels       : 1
	Sample Rate    : 22050
	File : one.wav
	Length : 11392
	RIFF : 11384
	WAVE
	fmt  : 20
	  Format        : 0x11 => WAVE_FORMAT_IMA_ADPCM
	  Channels      : 1
	  Sample Rate   : 22050
	  Block Align   : 512
	  Bit Width     : 4
	  Bytes/sec     : 11100
	  Extra Bytes   : 2
	  Samples/Block : 1017
	fact : 4
	  frames  : 23391
	*** cd   : 12 (unknown marker)
	*** indx : 40 (unknown marker)
	data : 11264
	Sample Rate : 22050
	Frames      : 22374
	Channels    : 1
	Format      : 0x00010012
	Sections    : 1
	Seekable    : TRUE
	Duration    : 00:00:01.014
	Signal Max  : 32768 (0.00 dB)


strombrg@blee:~/libusb$ wav-decode < two.wav
	fmt  20
	fact 4
	cd   12
	indx 40
	data 11776: 13*512 == 6656, 11776 - 6656 == 5120: 5K difference

	Input Filename : one.wav
	Sample Size    : two-bits
	Sample Encoding: ima_adpcm
	Channels       : 1
	Sample Rate    : 22050
	File : two.wav
	Length : 11904
	RIFF : 11896
	WAVE
	fmt  : 20
	  Format        : 0x11 => WAVE_FORMAT_IMA_ADPCM
	  Channels      : 1
	  Sample Rate   : 22050
	  Block Align   : 512
	  Bit Width     : 4
	  Bytes/sec     : 11100
	  Extra Bytes   : 2
	  Samples/Block : 1017
	fact : 4
	  frames  : 24408
	*** cd   : 12 (unknown marker)
	*** indx : 40 (unknown marker)
	data : 11776
	End
	Sample Rate : 22050
	Frames      : 23391
	Channels    : 1
	Format      : 0x00010012
	Sections    : 1
	Seekable    : TRUE
	Duration    : 00:00:01.060
	Signal Max  : 32768 (0.00 dB)

Some info about codecs:

The sample data encoding is signed linear (2's complement), unsigned linear, u-law (logarithmic), A-law (logarithmic), ADPCM, IMA_ADPCM, GSM, or Floating-point. U-law (actually shorthand for mu-law) and A-law are the U.S. and international standards for logarithmic telephone sound compression. When uncompressed u-law has roughly the precision of 14-bit PCM audio and A-law has roughly the precision of 13-bit PCM audio. A-law and u-law data is sometimes encoded using a reversed bit-ordering (ie. MSB becomes LSB). Internally, SoX understands how to work with this encoding but there is currently no command line option to specify it. If you need this support then you can use the psuedo file types of ".la" and ".lu" to inform sox of the encoding. See supported file types for more information. ADPCM is a form of sound compression that has a good compromise between good sound quality and fast encoding/decoding time. It is used for telephone sound compression and places were full fidelity is not as important. When uncompressed it has roughly the precision of 16-bit PCM audio. Popular version of ADPCM include G.726, MS ADPCM, and IMA ADPCM. The -a flag has different meanings in different file handlers. In .wav files it represents MS ADPCM files, in all others it means G.726 ADPCM. IMA ADPCM is a specific form of ADPCM compression, slightly simpler and slightly lower fidelity than Microsoft's flavor of ADPCM. IMA ADPCM is also called DVI ADPCM. GSM is a standard used for telephone sound compression in European countries and its gaining popularity because of its quality. It usually is CPU intensive to work with GSM audio data.