I just want to make sure that the development team is aware of this. It’s causing a major headache for me as we use GSM recordings for all our clients, because it takes up 1/10th of the space that WAV files do. I’d like to move all our clients up to the new FreePBX 12, but I can’t without choosing between storage issues or the inability to listen to call recordings (Aside from FTP’ing into the spool folder and retrieving the individual audio files and listening with quicktime of course.)
Is this permanent? Or is the dev team planning on expanding the new CDR call recording player to be able to process other audio codecs?
wav (not WAV) are uncompressed files, and are roughly 10 times the size of WAV (wav49) and gsm which are are comparable in size. but you can’t be using apple stuff if you use WAV.
As Dicko slightly stated you are SOL. That is because HTML5 standards do not support browser playback of GSM. All files will have to be converted on the fly by UCP into wav/ogg/mp4 to support the vast majority of Browsers.
Right now we convert any wav file into ogg as a start however we will be converting more formats. Unfortunately this can not be done “on the fly” when the play button is clicked as it would not be instantaneous, they have to be converted before hand.
Supported formats are listed here: http://jplayer.org/latest/developer-guide/#jPlayer-media-encoding
Perhaps there will be an option in UCP to disable “web playback” which will save you hard drive space, you can then click the download link for each file.
Yes I know this “worked” differently in ARI but that was really a half-assed attempt at making something work and goes against all web standards. We will not be doing it this way moving forward.
I understand. It’s unfortunate, but some conveniences must be sacrificed in the name of progress. Thank you for your suggestions.
IMHO It’s a problem that there isn’t a way to keep the old interface intact so that the old player could be used. This was working for my clients yesterday, but since upgrade to 12 tonight, it’s broken. We also cannot use wav (we use WAV/wav49/gsm) - because it takes 10x less storage and we have to keep more than a couple of months of files online.
Is there any plan to make jPlayer support gsm in the future, or to at least allow us the option of keeping the old (non html5/jquery) player until it is?
The old play was a hack and forcefully required quicktime and then you had to make sure quicktime player had the GSM codec. I will never bring back the quicktime player.
jplayer will never ever support GSM. Are you asking if there are plans to convert gsm into HTML5 spec files?
I guess the question is what we should do and if you have any suggestions. I would imagine that there are a fair number of people using call recording for QA purposes like all of my clients do. This means that they keep up to a years worth of recordings in local storage before archiving up to 5 years of calls. Because of the volume, we have to use a compressed format, but also need to be able to play them via a web page and would prefer not to transfer them to another platform for playback. I’m sure we’re not alone. If we use a job to convert them to mp3 with sox or something would that work, or is there any other jquery component that would support gsm/WAV that you know of? Otherwise, is converting them to a non-gsm format in real-time prior to clicking play the only way to make the existing player work?
Uncompressed Wav is already supported by the HTML5 spec. These are HTML5 specs. It has nothing to do with jquery. The supported formats are: wav, mp3, ogg, acc.
I previously stated why this wont work. It takes time to transcode a file. While it’s transcoding do you really expect your end user to sit there and wait?
If we convert the files to OGG only they will use about as much space as your GSM files.
I don’t make the rules of the internet I just follow them: HTML Audio