GNOME Bugzilla – Bug 598028
support weird wav/adpcm files in a ".REC" format
Last modified: 2018-05-04 09:05:57 UTC
I have a trusty old iRiver IFP-180T, which I use as a voice recorder. It creates some weird .REC files, which I so far used to convert with a binary called "ifprecconv", part of http://ifpgui.sf.net (docs here? http://ifpgui.sourcearchive.com/documentation/0.12.0-1/files.html), which uses sox, it seems. Playing the .rec files in a gstreamer app such as totem yields audible but garbled sound, which gives me some hope that maybe it could be handled by gstreamer. I'm in no position to provide a patch, but filing this in the hope that perhaps gstreamer could support those files natively, which would be real nice.
Also, if it can be of help, sox gave this hint: jeff@kusanagi:~/lala$ ./../ifprecconv VOICE000.REC I'm going to run 'play -r 32000 -c 1 -t raw -f s -w /dev/stdin'
Could you provide a sample file?
Created attachment 145223 [details] sample recording Well damn, I thought I had attached it with the initial report. Here it is :) bugzilla probably freaked out on the mimetype, so I'm uploading it as "application/octet-stream".
detected as : /data/sample.REC: RIFF (little-endian) data, WAVE audio, IMA ADPCM, mono 32000 Hz gstreamer, mplayer and xine all play it garbled.
Looks like ifpgui does some processing on the files: http://ifpgui.cvs.sourceforge.net/viewvc/ifpgui/ifp_gui/src/ifprecconv/ifprecconv.c?revision=1.1.1.1&view=markup
Yes, not sure how we could automatically detect this though...
Just a note: sox's -w argument has been deprecated, the command should now be: sox -r 32000 -c 1 -t raw -s -b 16 - foo.wav
We're now detecting this as "audio codec: DVI ADPCM audio", but it still sounds the same across gstreamer, mplayer, avplay and vlc. Also the sox command is just to play the decoded file. I think the interesting part would be to compare http://ifpgui.cvs.sourceforge.net/viewvc/ifpgui/ifp_gui/src/ifprecconv/adpcm.c?view=markup with the code in gst-plugins-bad - adpcmdec
I found some sites [1] stating """ However, iRiver does not follow this standard exactly, so standard libraries (e.g. libsndfile) will not decode it correctly. On Windows, you can use the iRiver software to convert to a standard PCM WAV file. On Linux, you can use another open source project, ifprecconv. """ So, we'd need to implement this adpcm variant in adpcmdec/enc, define a caps variant and we'd need to be able to somehow detect it. However I don't see any metadata in the file that we could use for detection :/ Shall we close this as WONTFIX? [1] http://projects.csail.mit.edu/cgi-bin/wiki/view/SLS/IRiver
Will this would be nice to support, it hasn't seen any activity in 3 years. And seems like a very particular use-case. If someone can provide a patch to properly detect and handle this, re-open this bug and provide patches.