Hello, I know it is a little bit off topic but I hope to get some helpful hints anyway.
At our local repair cafe I got asked if I could recover the message from a broken answering machine Gigaset C595. I think it is a message from her mother which has lately passed away.
I was able to desolder the SPI flash chip and recover the data with flashrom. If I import the raw file in Audacity (8bit, unsigned, 2000Hz, mono) I am able to barely hear a voice with lots(!!!) of noise at the very end of the data.
My guess is that the data is in 12bit format.
The main CPU is a NXP ARM PCD80725HL/E.
I tried binwalk, strings, foremost, hexdump/ghex, sox/play, audicity, python code (bit shifts etc.)
I am out of luck. Does anybody have a idea?
Hmm.
With telephony-related systems, I’d start with a sample rate of 8000 Hz.
Try alaw (and maybe ulaw) encodings as well, audacity can import both from the raw data importer.
It might also be ADPCM, which was popular for answering machines, but there are a ton of different ADPCM implementations. sox supports a number of different ones (like 4bit IMA, MS ADPCM, etc.)
It seems like you know roughly where the voice data is located. If so: Can you cut out a small sample of it (ideally 32bit or so aligned) and post it (or share it privately)?
EDIT: C595’s seem to be about 15 Euro on Kleinanzeigen, depending on how important/sentimental those messages are, it might also be worthwhile to just pickup another C595, transplant the flash chip and record analog audio from the speaker output?
I tested different sample rates and everything above 2000Hz was to fast. I tested uLaw, aLaw and all the other options offered by audacity. It was all worst than 8bit, unsigned, 2000Hz.
I started to look for a C595 anyway to go this two paths in parallel.
Ah! “Hier ist der Anrufbeanworter der Familie [censored], … etc.”.
Understandable audio, but still a lot of distortion and also a repeating clicking noise every few seconds (probably blocks/headers)
Yeah, that’s about the best output I managed to do.
2 problems:
distortion (might go away with understanding the header/block format and stripping that)
bigger one: this seems to be only the greeting itself, not any of the recordings made for incoming calls.
I had a brief listen to the “full” (only 1MB? really?) dump, but couldn’t hear any other audible voice/audio.
Wow this is great. I did it myself and it sounds impressive indeed.
Yes I have to ask if she wanted to recover the greeting instead of some message. She is a bit shy to talk about the background of the story (that’s why I guess a tragic background).
The flash is a 8MBit (1MB) which fits with the size of the image. There is nothing else I could find on the PCB (see picture).
The picture got compressed a bit. The chips are just on the top side of the PCB. I think the metal case is just the DECT RF part and I expect nothing message related under the shield. The CPU could have some memory but I highly doubt that.
Is it sensible to expect memory in the handheld part? I think the chances are even less that memory in the CPU.
Well, they do contain a lot of memory (2, 4 or 8 MByte, depending on the model), but from what I’ve seen so far, they mostly contain firmware & settings. Haven’t seen one with audio recordings yet.
Hm, I wonder if there might be messages encoded in one of the codecs DECT uses anyway, like G.726-32, etc.
Would probably be a bit tricky to decode, though
You mean encoded but in the SPI flash I was able to read, right?
Yes with the memory in the handheld was just to make sure to have mentioned it. I did really believed to see the message transmitted over DECT just to get it stored in the handheld.
Would there a way to find G.726-32 headers or typical patterns?
Hm, not really. It’s mostly a pure bitstream, signalling/headers have to be done externally (or not at all).
I’ve tried to use decode-g72x to decode the data, but sadly none of the available modes resulted in any valid output:
CCITT ADPCM Decoder -- usage:
decode [-3|4|5|62|63|64|65] [-a|u|l] [-n|L|R] < infile > outfile
where:
-3 Process G.723 24kbps (3-bit) input data
-4 Process G.721 32kbps (4-bit) input data
-5 Process G.723 40kbps (5-bit) input data
-62 Process G.726 16kbps (2-bit) input data
-63 Process G.726 24kbps (3-bit) input data
-64 Process G.726 32kbps (4-bit) input data [default]
-65 Process G.726 40kbps (5-bit) input data
Just a quick update. I got a second hand Gigaset C595. We found this version has a different CPU and the implanted flash did not work at all. Hint the body of the device says “Siemens Gigaset C595”. On the incorrect version it says “Gigaset C595 Siemens”.
Today I got another Gigaset C595 with the (hopefully) correct version. I might find the time to open it in the next few days and try another transplantation of flash memory.
BTW: I was unable to read the “other” flash with the C341 and will try to read it with a Raspberry Pi Pico at the weekend.
you are much faster. I started to read about G.726-32 and found something from 2010