Well, my idea was to dump the input file's worth of CELT frames to a text file, then parse the data given the known Packetsize number of bytes per frame. Since you know, for example, 40 bytes are in a frame, you could take the first 40, then the next 40, etc etc. This way I could model my packetization, FEC and RF channel in Matlab.<br>
<br>My other option is to buffer up a much smaller amount of frames on a DSP and dump those from memory to a text file. I was just hoping the command line could get me to an easier solution with a larger number of frames available to test.<br>
<br>I started looking into Ogg a bit more. I apologize, I assumed it was an Ogg Vorbis file. Now it makes more sense. I may try to go this route.<br><br>However, I will contest your statement that "raw CELT bytes" do not exist. I've seen them with my own eyes. :)<br>
<br><br><br><br><br><br><br><div class="gmail_quote">On Wed, Jun 1, 2011 at 12:13 PM, Benjamin M. Schwartz <span dir="ltr"><<a href="mailto:bmschwar@fas.harvard.edu">bmschwar@fas.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In a sense, there's no such thing as a stream of "raw CELT bytes".<br>
<br>
CELT can only be decoded after it's been broken into frames, and the frame<br>
boundaries cannot be determined by looking at the CELT data itself. A<br>
transport layer such as Ogg or RTP is required to provide this framing<br>
information.<br>
<br>
In your case, the easiest solution might be to process the Ogg stream in<br>
order to retrieve the CELT frame data. This is meant to be very easy;<br>
every Ogg player has to do it. The obvious alternative would be to modify<br>
the command-line tools to export CELT using your own nonstandard framing<br>
scheme.<br>
<br>
--Ben<br>
<br>
</blockquote></div><br>