See near the bottom for the interesting bit :-)

In article <[EMAIL PROTECTED]>,
Stephen R. Besch <[EMAIL PROTECTED]> 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.

I've just been playing with these files too. You can play the audio using:

tail +513c ring1.bin | play -t ul -

> Here is a partially decoded header:
> 
> 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)

This is the year (2004)

> 0C            0419 or 0505 ?

The month and day (Apr 25 or May 5)

> 0E            82A, 140B, 142C  ?

I assume the time in hh:mm (08:42, 20:11 or 20:44)

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

Useful information. I think there's enough there to recreate these files
now (don't know about the 0000 or 00C8 at offset 26 though).

OK, while composing this post I decided to write a perl program to read
a uLaw stream on standard input and create a suitable header, writing
the result to an output file.

It can be found at http://www.softins.co.uk/makering.pl.txt

Save and rename to makering.pl. Usage is described in the file, but here
is an example:

sox inputfile -r 8000 -c 1 -t ul - rate | makering.pl ring1.bin

(try using /usr/share/sounds/phone.wav for the inputfile)

After putting the ringN.bin file into /tftpboot and rebooting my phone,
amazingly enough it works! I now have a new ringtone.

Time for bed....

Cheers,
Tony
-- 
Tony Mountifield
Work: [EMAIL PROTECTED] - http://www.softins.co.uk
Play: [EMAIL PROTECTED] - http://tony.mountifield.org
_______________________________________________
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

Reply via email to