Okay, so I have a RAW audio file that I’m trying to decode, but I’ve tried every combination in the raw input dialogue that I can think of. I’m using Audacity 2.0.5 on OS X 10.8.5.
I’m attaching the file in case anyone else has any more luck with it than I have. I can partly hear the audio by setting input of 8-bit signed PCM stereo and a sample rate of 22050Hz but there’s a lot of white-noise. A setting of 16-bit signed PCM at 11025Hz works as well, but with even more noise in the audio. It doesn’t seem to matter whether I select signed or unsigned (the sound is about as noisy under both settings). I’ve also tried reducing to a single channel, but that doesn’t seem to help much either.
Am I just missing a combination? It feels like I’m close to figuring out what settings the file requires, but I just can’t for the life of me get it to clear up completely, but I don’t really have enough experience with this, I’m hoping someone with a more finely trained ear can tell where the problem might lie. I’ve seen mentions of 4-bit PCM encodings (a flavour of ADPCM?) but Audacity doesn’t have that, and the ADPCM mode it supports doesn’t seem to be right either unfortunately.
I’m attaching the file, which should give a brief line of a woman’s voice; this single file isn’t all that important, but I have a heap of similar files and (hopefully) the settings should all be the same.
You did not attach a file (note there is a 1 MB limit for files attached here). See How to post an audio sample .
Also note that Import Raw Data is only for uncompressed audio.
There is also a bug in Import Raw Data that files import as noise if Default Sample Format in the Quality section of Preferences is set to 24-bit, so make sure that is set to 32-bit or 16-bit.
Ah, forum doesn’t allow .raw extensions, I must have missed the error message and thought it had finished, here it is zipped this time.
My quality settings were already on 32-bit (float), but 16-bit doesn’t seem to help either unfortunately TD9EV1TC.RAW.zip (160 KB)
I think you’ll have to ask the person who gave you the files.
I agree it sounds best at signed 8-bit PCM. The file seems to sound better as Big Endian and I think 44100 Hz sounds right.
I don’t think you can do much with the noise (I am not an expert in this). I removed all the 00’s and 0F’s which appeared to be padding (using a hex editor) which has somewhat lessened the noise.
Endianess refers to the byte order, thus it doesn’t apply to 8-bit.
However, it becomes important when we merge two bytes together.
In this case, the sampling rate has to be halved.
We can equally assume two channels-- another halving.
Plenty of combinations, I think.
Unfortunately I don’t think that’s possible, they’re really old files that I was hoping to move to another format
I wrote a quick script using sox (since I’m not sure if Audacity has a command-line interface?) to produce what I think is every combination of the file:
#!/bin/sh
alias sox='/opt/local/bin/sox'
while [ $# -gt 0 ]; do
[ ! -f "$1" ] && { echo "Invalid path: $1" >&2; continue; }
clean_path=$(printf '%s' "$1" | sed 's/.[^.]*$//')
for bits in 8 16 24 32; do
bits_mod=$(($bits / 8))
for channels in 1 2; do
channels_mod=$((($channels)))
sample_rate=$(((44100 / $bits_mod) / $channels_mod))
encodings='unsigned signed'
[ $bits = 8 ] && encodings="$encodings a-law u-law"
for encoding in $encodings; do
out="${clean_path}_$bits-bit($encoding)_$channels-channels"
options='--rate "$sample_rate" --encoding "$encoding" --bits "$bits" --channels "$channels"'
if [ $bits -gt 8 ]; then
for endianness in little big; do
eval "sox $options --endian "$endianness" "$1" "${out}_$endianness-endian.wav""
done
else
case "$encoding" in
(?-law)
for ordering in '' '-X'; do
[ -n "$ordering" ] && suffix='-reverse' || suffix=
eval "sox $options $ordering "$1" "$out$suffix.wav""
done
;;
(*)
eval "sox $options "$1" "$out.wav""
;;
esac
fi
done
done
done
shift
done
Just pass it a path to the .raw file and it’ll produce .wav files of most combinations (except 32-bit and 64-bit float), except ADPCM as I couldn’t get that to work. Unfortunately none of them is completely clean, so I suspect there’s something weird with the format, I just don’t know what.
But that raises a question whether I was hearing a placebo effect with Big Endian (perhaps, yes) and why the endianness options are enabled in Import Raw for formats of 8-bit or below.
I don’t think the noise reduction when “packing” the data is a placebo effect, and I do think it is noisier in stereo at half the sample rate and at 16-bit at half the sample rate.
The only major format missing from Audacity’s Import Raw is IMA ADPCM, but I doubt this is a 4-bit file because that would mean it was probably 88200 Hz.
Yes, this choice should actually be greyed out.
I’m not sure but I think a similar thing was applied to the order of nibbles, i.e. 0x2A → 0xA2.
However, that was in the very beginning of cybernetics.
I don’t think the noise reduction when “packing” the data is a placebo effect, and I do think it is noisier in stereo at half the sample rate and at 16-bit at half the sample rate.
Packing? Do you mean companding (a-law/mu-law) or putting bytes into words?
If I do factorize the length, I get: 2 * 2 * 17 * 3181 bytes, i.e. not divisible by 3, thus 24 bit or 12 bit encoding falls away.
For 16 bit, stereo is possible but very unlikely because the sample rate is so low.
However, interpreting it as stereo 8 bit, 22050 and isolating the center removes a lot of the initial noise.
I still wonder where those intermittent values come from: The beginning is nearly always 0 but at certain places, 143 is thrown in (byte # 17 27 43…).
The only major format missing from Audacity’s Import Raw is IMA ADPCM, but I doubt this is a 4-bit file because that would mean it was probably 88200 Hz.
or stereo.
Well, we could try exporting a test sentence as ADPCM and listen to it when it is imported as 8-bit Raw.
I personally suspect some proprietary format that just uses its own code book.
This would explain the value 143 from above, it could internally be translated to a very small amplitude (which, of course is already the case when we work with 16 bit, i.e. 143/65536).
Audio Actors are Audio Interchange Files (AIFF) that are interactively played back. Audio actors are 16b @ 44.1 kHz samples compressed @ 3:1. Audio actors are ~300kB.
It’s from a design document, so it’s entirely possible that the format was changed, and I couldn’t find any mention of which samples (if any) are expected to be in stereo, though my suspicion is that some are and some aren’t. This seems like it could mean the file is actually a header less AIFF-C, rather than a typical RAW file, which means there are unfortunately more compression types that I’ll need to read up on and see if I can figure out. This might explain the padding sequences that Gale Andrews noticed.
On Wikipedia the only listed format that claims 3 to 1 compression is MACE 3-to-1, but I’m not aware of anything that claims decoding support.
I just did what I said, removed the 00 and 0F values, because in a hex editor these just look like “padding” between the data and it’s been observed before that this type of padding can create noise or incorrect detection.
I don’t know a great deal about this but a patch greatly improving raw import detection is planned for inclusion in 2.0.7.
