Incorrect encoding of "WAV" recordings?

Questions
1

I’ve recorded some of my SuperCollider pieces as “WAV” files from SuperCollider.

And those files are barely recognizable by other applications.
dBpoweramp is not able to find encoding those files have, my Java and JavaFx app are not able to play them, … While they are no issues with regular PCM or IEEE encoded files.

This is the recording instruction (for a pattern):
.record(server: s, clock: t,quant:4, path: ~file, dur: nil, headerFormat: "WAV", sampleFormat: "int16")

When I reopen the file as a SoundFile (in SuperCollider), I see that the headerFormat is “AIFF” and “float”, despite my instructions:

image

So bug in SuperCollider or error of me ?

2

My best guess is that you might be using an old version of SC where this wasn’t working.

With the current in-development version, I can’t reproduce the problem:

s.dumpOSC(1);

Pbind(\degree, Pseries(0, 1, 2), \dur, 0.5).record("~/test0307.wav".standardizePath, numChannels: 2, server: s, headerFormat: "WAV", sampleFormat: "int16");

// preparing for recording includes this server message
// format is specified correctly
    [ "/b_write", 0, "/home/dlm/test0307.wav", "WAV", "int16", 0, 0, 1, 0 ]

s.dumpOSC(0);

f = SoundFile.openRead("~/test0307.wav".standardizePath);
f.dump;

Instance of SoundFile {    (0x5625a8186e28, gc=F0, fmt=00, flg=00, set=03)
  instance variables [7]
    fileptr : RawPointer 0x5625a3069f70
    headerFormat : "WAV"
    sampleFormat : "int16"
    numFrames : Integer 76864
    numChannels : Integer 2
    sampleRate : Integer 44100
    path : "/home/dlm/test0307.wav"
}

f.close;

I do see a recent change to the Recorder class, which could relate to the file format. That was introduced into SC 3.11.2 but I’m pretty sure it isn’t in 3.11.1.

So, if you’re using 3.11.1 or before, it could be an SC bug.

BTW another possible workaround: Audacity doesn’t complain if the recorded format doesn’t match the file extension (I tested this). That is, it looks like the logic for the other tools you mentioned is “this file is named .wav; therefore it must be wav; oh look, the file header isn’t wav; therefore the entire file is garbage and I’m refusing to do anything” (which is fantastically user-friendly process design, right? wonderful use of developer hours, to make it harder for the user… :man_facepalming: ) Audacity’s logic is, “eh, filename, whatever, this is an AIFF header, so I’ll open it that way.” Then you could export from Audacity.

hjh

3

Well I’m on 3.11.2, and I re-tested exactly with the same instruction as you (except for the filename) and the error is reproduced:

    Instance of SoundFile {    (000000000B5ECE08, gc=7C, fmt=00, flg=00, set=03)
      instance variables [7]
        fileptr : nil
        headerFormat : "AIFF"
        sampleFormat : "float"
        numFrames : Integer 0
        numChannels : Integer 1
        sampleRate : Float 44100.000000   00000000 40E58880
        path : "E:DiversSuperColliderRecordings105_Granules1..."
    }

I’m running on Windows 7.

4

Could you check the path and run the test again? Nothing was recorded that time, and the path looks like single backslashes were in the string.

Also dumpOSC and quote the b_write message.

hjh

1 Like
5

I’ve just tried 3.11.2 (in Linux), no problem.

So the class library definitely sends the right format strings to the server, to open the output file. If the class library were not sending the format string, then I would see the problem too.

My next best guess, then, is that maybe scsynth in Windows 7 doesn’t handle the format string correctly…? Which would be weird.

hjh

6

Corrected.
Double issue at my side. At recording, my “headerFormat” was “headerformat” instead of “headerFormat” (initial issue). And at analysing, I was using plain “\” in the filename instead of “/”…
Thanks James for your time.