Vorbis dev - Jun 2012 - [libtremor] ov_read is reading past file size

I have a wav file which has been converted to an ogg file with libvorbis 
via ffmpeg.  However I've tested a few files just to make sure.

I run a standard while loop to using ov_read to pull all the data out of 
ogg file.  Using 4096 as the size to read each call.  Watching my debug 
logs it is reading 2048 bytes each call.

When I load the wav file the data chunk for the pcm data is 167680 
bytes.  Running the file in audacity proves this size to be accurate.

When I load the ogg file, ov_read goes past that size ending on 168320 
bytes, which causes some memory corruption further down in the program.

If I force the while loop running ov_read to stop one read before, 
166272 bytes, then everything is fine except the sound clip cuts off a 
few samples early.  If I let it do the final ov_read call it attempts to 
read up to 168320 bytes, which is past what the PCM data actually is and 
the allocated buffer size.

unsigned int uiPCMSamples = (unsigned int)ov_pcm_total(&vf, -1);
unsigned int totalPCMSize = uiPCMSamples * vi->channels * sizeof(short);
void* pvPCMBuffer = malloc(totalPCMSize);

This yields 167680 bytes, so tremor knows how much PCM data there is.  
However ov_read is just going ahead and skipping past that number 
reading up to 168320 bytes.

So either I have to increase the size of my pvPCMBuffer by some magic 
number or tremor is reading to far.


         int current_section = 0;
         long iRead = 0;
         unsigned int uiCurrPos = 0;
         do
         {
             iRead = ov_read(&vf, (char*)pvPCMBuffer + uiCurrPos, 4096, 
&current_section);
             uiCurrPos += (unsigned int)iRead;
         }
         while (iRead != 0);


I've tried everything assuming I'm the cause of the problem.  Although 
now I am leaning on tremor having an issue.


(I posted to tremor mailing list first but it is labelled as deprecated 
and pointed to this one as the mailing list for it)


Thanks,
Stephen Damm

On 12-06-09 06:26 PM, Stephen Damm wrote:
> I have a wav file which has been converted to an ogg file with 
> libvorbis via ffmpeg.  However I've tested a few files just to make
sure.
>
> I run a standard while loop to using ov_read to pull all the data out 
> of ogg file.  Using 4096 as the size to read each call.  Watching my 
> debug logs it is reading 2048 bytes each call.
>
> When I load the wav file the data chunk for the pcm data is 167680 
> bytes.  Running the file in audacity proves this size to be accurate.
>
> When I load the ogg file, ov_read goes past that size ending on 168320 
> bytes, which causes some memory corruption further down in the program.
>
> If I force the while loop running ov_read to stop one read before, 
> 166272 bytes, then everything is fine except the sound clip cuts off a 
> few samples early.  If I let it do the final ov_read call it attempts 
> to read up to 168320 bytes, which is past what the PCM data actually 
> is and the allocated buffer size.
>
> unsigned int uiPCMSamples = (unsigned int)ov_pcm_total(&vf, -1);
> unsigned int totalPCMSize = uiPCMSamples * vi->channels * sizeof(short);
> void* pvPCMBuffer = malloc(totalPCMSize);
>
> This yields 167680 bytes, so tremor knows how much PCM data there is.  
> However ov_read is just going ahead and skipping past that number 
> reading up to 168320 bytes.
>
> So either I have to increase the size of my pvPCMBuffer by some magic 
> number or tremor is reading to far.
>
>
>         int current_section = 0;
>         long iRead = 0;
>         unsigned int uiCurrPos = 0;
>         do
>         {
>             iRead = ov_read(&vf, (char*)pvPCMBuffer + uiCurrPos, 4096, 
> &current_section);
>             uiCurrPos += (unsigned int)iRead;
>         }
>         while (iRead != 0);
>
>
> I've tried everything assuming I'm the cause of the problem. 
Although
> now I am leaning on tremor having an issue.
>
>
> (I posted to tremor mailing list first but it is labelled as 
> deprecated and pointed to this one as the mailing list for it)
>
>
> Thanks,
> Stephen Damm
Solution was simply to add:

ov_pcm_seek(&vf, 0);

Not entirely sure why.  No other examples do this.  However all the size 
reads line up now.