Serge Oleinikov wrote:
I did a little detective work and here is a summary of what I found out. In version .63 of the firmware, the ringtone files are all nearly identical (at least they contain the same audio data stream). From this, and from the format of the hex data in the header, I was able to discover the location and format of the checksum. The idea is that the only differences in the files were the file name field, the checksum word and one other value (the 00C8 at offset 26). From this it was possible to compute the difference in checksum expected and show that the only value in the file that changed appropriately was at offset 2. It also revealed the means of calculating the checksum. Here is a partially decoded header:I was trying to replace the header. But looks like header contains some kind of CRC
The format the rings are at are after what I found out uLaw compressed 8bit 8000hz mono samples. But they also have a header infront of the file. I will play arround with it later. Maybe there is a way to chop off the header of the ones that come with it and put it infront of a regular file.
Hex Offset Typical Value Function 00 0000 ? Always zero (6 sample files) 02 7F90 File length in 16-bit words (bigendian) 04 3450 Checksum (see below) 06 01000000 Version number 0A 07D4 Always this value (6 samples) 0C 0419 or 0505 ? 0E 82A, 140B, 142C ? 10 Text filename (eg ring1.bin) 19-25 0's ? 26 0 or 00C8 ? 28-FF 0 ? 100 0100 **See below 102 7F90 repeat of length 104-127 0's ? 128 Text String describing file 147-1FF 0's ? 200-end Audio Data
The checksum is the value that must be put into location 2 so that a 16-bit sum of the entire file, ignoring overflow, is exactly 0. It is essentially the negative of the sum of the file computed with a zero value in the checksum.
The value in location 100 is interesting. I suspect that it is either the length of the buffer which follows and contains the file comment, or it is simply the offset to the data stream. Since is sits at location 100, it is impossible to tell which. Some further experimentation might resolve the issue. If anyone can fill in the remaining fields, it would be cool.
Hope this helps.
Stephen R. Besch _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
