QDesign Music. A quick analysis by. Benjamin Larsson

Transcription

1 QDesign Music A quick analysis by Benjamin Larsson banan@student.luth.se Version th January 2004

2 Contents 1 Abstract 3 2 Introduction 3 3 Test of QDM2 3 4 Assumptions 3 5 Facts General Blocktable Packet table Bitstream Checksum calculation routine Structure decoding Bitstream terminator Sound resynthesis Decoding procedure Further Progress 10 7 Comments 10 8 Version History 10 9 References Hexdump of packets Hz 24 kbit mono white noise Hz 24 kbit mono silence

3 1 Abstract This is an initial analysis of QDesigns audiocodecs QDMC and QDM2 (QDM aka QDesign Music). The goal is to eventually understand the structure of the codecs and finally be able to decode it. 2 Introduction QDMC is an audio compression-codec from QDesign. It is mainly used in Quicktime [2] from Apple. So far very little is(was) known about this codec. It seams to originally come from Dmitry Shmunk s LB codec. (Low bitrate codec). He was abit active on usenet 96-97, he made the LBpack/LBplay media player. From the history in one of the version of his mediaplayer [4], there is a note of using a Radix-4 FFT implementaion in the player. No other useful information could be found about the technique used for the codec. The only other source of information seams to be from QDesign themself from their pressreleases [1]. The only valuable information from those is that QDMC is a perceptual codec. That indicating a propritary psycoacoustics implementation. Although the pressrelease for QDMC says it is fundamentally different from anything else available at the time (98), one could suspect that this fundamentally difference is in one of the steps of a sub-band codec. And not some other form of approach of compression. This document will mostly describe QDM2 because the MVP [5] program from QDesign could only encode in that format. Most work is done with 24kbit mono files and that might affect sertain assumptions and facts. 3 Test of QDM2 Testing was done with chirps. The chirp was created with matlab and normalized with a 0.8 factor. A sweep from 0 to khz (figure 1) showed that somthing happened around 8kHz. A powerspectrum plot (figure 2) revealed that most of the higher (> 8kHz) frequencys are not there. And some strange pattern is repeted 3 times after the drop. If you compare figure 2 with figure 3 striking similarities are found, figure 3 is a powerspectrum plot of a µlaw-converted version of the chirp wavform. The µlaw-conversion is basicly a logaritmic quantization reducing the amount of bits per sample from 16 to 8. This strongly indicates a use of a logaritmic pcm step in the codec. A chirp test with a higher normalization factor (> 0.9) gave the results shown in figure 4. 6 visible overtones can be found, this indicates some sort of numerical stability, maybe some overflow/rounding error in the encoder. Though some litte trace can be found in figure 2, a close look reveal two lines forming a X. 4 Assumptions Right now I m guessing this is a sub-band codec with many conceptual similarities with Layer 2 and 3 of the Mpeg audio codecs. Some use of VLC/RLE/Huffman. Maybe even VQ. IDCT used to resynthesis the sound. QDM2 is the same co- 3

4 1 QDMC2 sweep , fs= Frequency Time x 10 4 Figure 1: Simple frequencysweep dec as QDMC but maybe some small changes in the bitstream or the steps to code/decode. 4

5 0 QDMC Hz 10 Power Spectrum Magnitude (db) Frequency Figure 2: Powerspectrum HzSweep.au.wav 10 Power Spectrum Magnitude (db) Frequency Figure 3: Powerspectrum 5

6 Figure 4: Frequency sweep with overtones 6

7 5 Facts 5.1 General QDM2 resides in a mov container. The container has information about the samplingfrequency and mono/stereo. The codec is a CBR codec. 5.2 Blocktable The codec works in even blocks and blocksize depends on the samplingfrequency. A block consists of 16bit PCM sampledata. The data that is compressed is simply divided in an even amount of peices. Samplingfrequency (Hz) Blocksize (bytes) Table 1: QDM2 blocksize-table. Zeropadding is used to fill an even number of blocks. 5.3 Packet table A compressed block forms a packet accoarding to table 2. Bitrate (kbits) Packetsize (bytes) Table 2: QDMC2 packet-table. Mono and stereo data seams to have the same packetsize, this indicating some form of joint-stereo compression. 5.4 Bitstream A packet is assumed to have a X bytes long header and after that the compressed data. The following has been able to be figured out by looking at hexdumps of the compressed packets. (Table 3.) Table 3 shows the common difference found between files of different bitrate. And by taking the 2nd and 3rd byte 7

8 and converting it to deciamals, table 4 appears. The numbers in that table is the exact lenght of a packet - 3 bytes. My guess is that the decoder uses this value to know how many more bytes it need to read. With all this information the following headertable is formed. (Table 5) Checksum calculation routine Checksum is calculated the following way. Summerize every value in a packet, except byte 4 and byte 5. And the result so the length is a 16bit number. Store the 16bit value divided in byte 4 and byte 5. The following code will calculate the checksum (the packet is represented as a 278 long vector with 8 bits unsigned numbers): Matlab: checksum = dec2hex(uint16(sum(packetvector(1:128))-sum(packetvector(4:5))) Pseudo C (I m no C programmer): pbyte4 = packet[byte4]; pbyte5 = packet[byte5]; sum = sum(packet); summinus = sum - (pbyte4 + pbyte5); checksum = summinus && 0x0000FFFF; The result checksum should be byte 4 and byte 5. The order is swapped in QDMC and QDM bitrate (kbit) XX XX XX XX E3 XX XX XX XX CB XX XX Table 3: QDM2 bitstream-table, the first 6 bytes. hex dec E CB 1483 Table 4: Hexadecimal to decimal 8

9 Byte number in header Description 1 Identifier, seams to always be 0x82 2,3 Amount of bytes before the packet ends (in hex) 4,5 Checksum value 6 Unknown structure Id value, always seams to be 0x09 7 Lenght of structure 8 Unknown, sometimes it is the same through a whole packet Table 5: QDM2 headertable. Samplerate may not be included in the bitstream, I found 24kbit packets with same content (zeros) but from different samplingfrequencys. Indicating that the bitstream does not have any samplingfrequency information. That information can be red from the movcontainer Structure decoding Inside a QDM2 packet there are some structures. Those structures has an id and a length. The procedure to get out all id s and lengths is as follows: set locationpointer to offset of byte 6 Do save the idvalue (&locationpointer) save the lengthvalue (&locationpointer + 1) set locationpointer to locationpointer + lengthvalue +2 Repeat If the idvalue and lenghtvalue is 0 then break the loop Bitstream terminator Bitstreams seams to need 2 NULL bytes to end a packet. Maybe needed for breaking structure calculation. 5.5 Sound resynthesis The resynthesis from the spatial domain to the temporal domain is done by an idct [6]. The idct is working with chunks of 64bytes. For 1 packet there are 8 chunks = 512, 512 bytes gets 1024 bytes after µlaw-conversion. 5.6 Decoding procedure Steps included in the decoding of a QDM2 packet. Check checksum Decode structures Magic (bit shaving, rle, vlc, huffman, etc..) idct 9

10 µlaw to 16-bit pcm 6 Further Progress More progress can probably be made by looking at hexdumps of packets but most likely dissassembly is a faster way. Proposed way is to make a short movfile with one packet, and then trace what is happening with a debugger. The first step should be some form of unpacking with huffman tables or not. Under linux the approach with mplayer [3] and gdb would be taken. With mplayer it would be easy to know where in memory the packet is and when access to that memory occurs. 7 Comments This document is a work in progress and will be updated if/when new information occurs. Most information should be correct but non is guaranteed. If anybody want to help with information just mail it. 8 Version History 1.0 Initial version 1.1 Added checksum calculation algorithm, fixed tyupos and more references 1.2 Added idct and structure information 9 References References [1] htm [2] [3] [4] ftp://ftp.simtel.net/pub/simtelnet/msdos/sound/lbit157.zip [5] [6] id= &forum id= Hexdump of packets Just for reference 2 hexdumps are included. Hexcat is used. And by looking at the amount of zeros in the packet of silence it makes sence that a packet with no information is easy to compress. Numbers between [ ] are strucure positions. 10

11 Hz 24 kbit mono white noise [09 21]7c 13 6b be 89 0b b f e2 9b d f f2 cd 6b 7a f1 01 0d 05 [0d 05] [ ]16[25 1f] 05 1a c8 08 bc fc 2c a 94 0a ba c5 1a 1d e9 48 5c e9 1b f5 b2 29 1c [24 42]09 3a a6 8c dc f b8 ac ab 7d a4 b8 0c a d 0e 66 3f c6 49 0c 0a 98 4c 8b 48 c5 80 2b a6 69 c a a a 16 a0 05 0f a b 9b 48 2a 20 e9 01[23 5b]0d e3 2e ee a f a b0-83 c a d c0 - d9 54 c2 13 e af c e d e d 82 1a e0-0b b cc a f0 - b8 a6 31 0a [22 1e]b5 92 f0 cd ca 52 d7 5a eb df e c9 b0 a6 b5 0a f 27 a4 84 e7 f5 ca ae d5 fa 01 [00 00] Hz 24 kbit mono silence c da[09 13]cc 2f 93 f bf 4c e c9 fc f 26 f3 cb 04[0d 05] [26 01]16 [25 01]55[24 01]55[23 01] 20[22 01] [00 00] a b c d e f