Hi Kevin,
1/ The mode number can imply a sample rate:
mode = CODEC2_MODE_2400WBA;
codec2 = codec2_create(mode);
Fs = codec2_sample_rate(codec2);
2/
> It might make sense to keep a flags byte around for --natural and
> --softdec. I haven't used these so I don't know much about them.
These flags have been used from time to time to support my digital voice
over radio work.
3/
> My plan is to add some code to c2enc/dec to see if the codec2 filename
> argument ends in ".c2".
I like that.
Cheers,
David
On 25/07/17 06:48, Kevin Otte wrote:
> I like your magic_id better :)
>
> The reason I looked at the mode byte is because that's what c2enc/c2dec
> (by way of a #define) use to set up the codec2 instance.
>
> codec2.h:
> #define CODEC2_MODE_1300 4
>
> c2enc.c:
> mode = CODEC2_MODE_1300;
> ...
> codec2 = codec2_create(mode);
>
> Samples per frame, bits per frame, etc are all defined in the codec2
> internal structure:
>
> nsam = codec2_samples_per_frame(codec2);
> nbit = codec2_bits_per_frame(codec2);
>
> So it really doesn't make sense to represent these values in the header
> when the code can figure it out from a single byte.
>
> samplerate is something of a sticky wicket. For now the only outlier is
> WB at 16Khz. Ideally I'd like to see the whole pipeline work at 48KHz
> and let the FFT do the voodoo, but that's a whole other thread. I think
> I'll leave that alone for now.
>
> It might make sense to keep a flags byte around for --natural and
> --softdec. I haven't used these so I don't know much about them.
>
> At present we don't do any FEC in the raw streams, only on the air (eg:
> with freedv_tx/rx not c2enc/dec).
>
> The version stuff might be useful for detecting future backward
> incompatible changes, but my gut feeling is YAGNI. I'd be interested to
> hear David's thoughts on that.
>
> So, that leaves us with a simpler header:
> struct Codec2Header{
> magic_identification :u24b, // offset 0 bytes
> // const 0xC0DEC2 ([0xC0,0xDE,0xC2])
> major_version :u8, // offset 3 bytes //
> minor_version :u8, // offset 4 bytes //
> mode_id :u8, // offset 5 bytes //
> flags :u8, // offset 6 bytes // default 0
> };
>
> Two bytes less if we ignore the version stuff.
>
> My plan is to add some code to c2enc/dec to see if the codec2 filename
> argument ends in ".c2".
>
> In the case of the encoder, if it sees that file extension, it will
> write the file header and then proceed to write as normal. Otherwise
> behave as it does today.
>
> In the decoder, if that extension, try to parse the header and set the
> mode. If the magic is wrong, seek the file back to zero and honor the
> command line mode argument / flags. I don't want to change the argument
> order as to not break old scripts. This means when using a valid .c2
> file the mode argument could be invalid, eg: ./c2dec foobar test.c2 -
>
> 73 de Kevin N8VNR
>
> On 07/24/2017 01:05 PM, txp0wer via Freetel-codec2 wrote:
>> Hi folks!
>>
>>> That said, the notion of managing the different bitrates does present a
>>> challenge. I therefore suggest any such encoded file have some "magic"
>>> bytes at the beginning, even if this is something as simple as 0x43 0x32
>>> ("C2"). I then propose the next byte be the mode ID as defined in
>>> codec2.h. This would allow c2enc/c2dec to be retrofitted or separate
>>> tools to be constructed to Do The Right Thing™ based on these.
>>
>> May I suggest a bitstream header format that encodes all the profile
>> parameters, so that new profiles can be added without changing the
>> header format or adding new "magic" numbers for profiles.
>>
>> 73 de txp0wer
>>
>>>
>>> If we can agree on these bytes, I'm happy to take a stab at coding this
>>> up. It doesn't look like it should be too difficult (famous last words!)
>>>
>>> 73 de Kevin N8VNR
>>>
>>> On 05/22/2017 04:35 PM, Kevin Otte wrote:
>>>> Or Matroska (.mka):
>>>> https://matroska.org/technical/specs/index.html
>>>>
>>>> On 05/22/2017 02:28 PM, Bruce Perens wrote:
>>>>> See https://www.xiph.org/ogg/doc/rfc3533.txt . Make it work with the
>>>>> Ogg Encapsulation Format.
>>
>> <code language="pseudocode" style="Rust">
>> // data types:
>> // u8 == unsigned 8-bit integer
>> // u16b == unsigned 16-bit integer, big endian
>>
>> struct Codec2Header{
>> magic_identification :u24b, // offset 0 bytes
>> // const 0xC0DEC2 ([0xC0,0xDE,0xC2])
>> major_version :u8, // offset 3 bytes //
>> minor_version :u8, // offset 4 bytes //
>> forward_ec_level :u8, // offset 6 bytes //
>> flags :u8, // offset 5 bytes // default 0
>> subframes_per_frame :u8, // offset 7 bytes // 1 to 4
>> samples_per_subframe :u16b, // offset 8 bytes
>> samplerate_hz :u16b // offset 10 // default 8000
>> };
>>
>> struct Codec2SubframeParameters{ // offset 12
>> // repeated [subframes_per_frame] times
>> lsp_bits_per_frame :u8, // offset 12+4*n
>> pitch_bits_per_frame :u8, // offset 12+4*n+(0..1)
>> energy_bits_per_frame :u8, // offset 4*n+(0..1)
>> voicing_bits_per_frame :u8 // offset 4*n+(0..1)
>> }
>>
>> match forward_ec_level{
>> 0=>none,
>> 1=>"1200",
>> 2=>"1850",
>> 3=>"2000",
>> _=>undefined
>> }
>>
>> flags:
>> 0x01=NATURAL_BYTE_ORDER // --natural
>> 0x02=ALTERNATE_MODE_1 // "B"
>> 0x04=ALTERNATE_MODE_2 // "C", "D"
>> 0x08=ALTERNATE_MODE_4 // "E" .. "H"
>> 0x10=unused
>> 0x20=unused
>> 0x40=unused
>> 0x80=ALTERNATE_CODEBOOK_1
>>
>> </code>
>>
>> example (hex)
>> # "3200" default profile
>> # begin Codec2Header
>> 00: C0 DE C2
>> 03: 00 04 # version 0.4
>> 05: 00 # no forward error correction
>> 06: 00 # flags: gray code, no alternate profile, no alternate codebook
>> 07: 02 # 2 subframes per frame
>> 08: 00 a0 # 160 samples per subframe => 320 samples per frame
>> 0a: 1f 40 # 8000 Hz
>> # end Codec2Header, begin Codec2SubframeParameters
>> # # begin subframe 0 # if I understand codec2_encode_3200() right
>> 0c: 20 # 32 bits LSP
>> 0d: 00 # 0 bits pitch
>> 0e: 00 # 0 bits energy
>> 0f: 00 # 0 bits voicing
>> # # end subframe 0, begin subframe 1
>> 10: 12 # 18 bits LSP
>> 11: 07 # 0 bits pitch
>> 12: 05 # 0 bits energy
>> 13: 02 # 0 bits voicing
>> # # end subframe 1
>> # end Codec2SubframeParameters, begin data bitstream
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Freetel-codec2 mailing list
>> Freetel-codec2@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freetel-codec2 mailing list
> Freetel-codec2@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
