Just last night, I attempted to record a meeting in my Mumble server. The meeting lasted about 2 hours and 30 minutes, and I had been recording the entire thing, red dot next to my username and the recording time counter continuing like normal. I've recorded a longer meeting in the past, but it was multichannel and I had an issue with synching the audio files together because some who took part came in late and left before the end.
This time I recorded it as a downmix, set the location, and hit Start. At the end of the meeting I hit Stop and since no errors came up and the recording timer showed about 2 hours and 30 minutes I thought it had worked. I went to pull up the recording today to see how it sounded so I could trim and upload it and saw that the file size was 4.72 GB and the length was 00:22:36. The length tipped me off first about there being a problem, then the file size. I pulled it into Adobe Audition, since I've got the CC for being a college student, and I was given a notice that there was over 100 MB of non-audio data in the file and that only audio data would be read. I dismissed it and kept it loading in, and sure enough, the length stayed at 00:22:36. So I went to do a test export of the file, keeping the same settings as the original file, and the file size was less than 800 MB for the same length.
I'm thinking that the audio data past that point in the recording wasn't written to the file correctly, so now it can't be read 100%. Has this happened to anyone before? Does anyone know how to recover that data?
Hi. Haven't heard anyone mentioning such issues before. The desync for long multi-channel recordings is a known issue and should be fixed in recent snapshots (along with other recorder bugs).
Based on what you said it might be possible mumble fell behind encoding the audio and was quit before it could properly catch up. There was an UI issue around this in earlier mumble versions. However in downmix I wouldn't have expected that to happen unless there was a long period of silence followed by someone speaking right before the recording was ended.
If you didn't use a snapshot please check whether they give you similar issues. If you still encounter the issue with a current snapshot please be as specific as possible so we can attempt to reproduce the issue on our end (e.g. mention mumble version, platform, recording format, did mumble become unresponsive, etc.).
As far as I know, I'm just using Mumble 1.2.4, not a snapshot. Could it be because I had it save out as a .wav, so it was uncompressed? If so, I'll probably use .ogg the next time. Also, it cut off right as someone was speaking, maybe a second or two after they had cued up and had already started talking.
And I'm still needing to try and recover the data from that file... I'm hoping someone would have an idea or clue on how to do that. The information is pretty important to the community that was meeting and I doubt much of it was committed to memory.
Today I learned: Apparently wav files have a file size limit of 4GiB. See http://en.wikipedia.org/wiki/WAV#Limitations . So yeah. Recording with another format would fix that issue.
The WAV file format is pretty simple and judging from the file size all the content is there. WAV is a very simple format. I'm sure you'll find tools out there to recover it / chop it up.
Ok. That might work. Install: http://audacity.sourceforge.net/
Do. File->Import->Raw Data. Select your file. In the dialog that pops up configure 24bit PCM, little-endian and 48kHz sample rate (should look like http://images.devs-on.net/Image/DFMDAi3y8gMygNbe-ImportRawData.png). Then hit import.
You should get a working audio import with a short burst of noise in the beginning (that's audacity interpreting the file metadata as audio) you can cut away. Export to any long-recording capable format you want.
Hope that helps.
Ok, I imported the file according to your instructions, and it turned the file into pretty much nothing but white noise with random pockets of silence for 9 hours, 47 minutes, and 30 seconds. I even exported it into a .ogg format to see if something different happens, but nothing really changed.
Sounds like multiple settings are off. Make sure to select little endian and PCM 24bit. Your output device likely uses 192kHz samplerate instead of 48kHz judging from the length of recording you got out. I forgot mumble records in whatever your device is configured to. Try 192000 for the sample rate.
Oh, it's actually set to 44100Hz, just checked in the recording devices settings. Time to try again!
Update: Nope, no luck at 44100 or 192000. Still white noise.
Strange. I only tried with short audio clips and could import those without any issues. Maybe something else but header corruption happens once the file becomes to big. You could play with the alignment setting (1 or 2 could make a difference) but I'm not sure if anything will come of that. You could also try some other players like VLC which usually is relatively robust to file corruption and see what they say about the file.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.