Hmm, so it reported exactly half the number of buffers played relative to
blocks downloaded and 32 bits per sample rather than the 16 in the blocks.
Seems too much of a co-incidence to me. Could it be that the blocks each
contain 16 bits of data and two blocks are joined to make a 32 bit "buffer"?

> -----Original Message-----
> From: get_iplayer [] On
> Behalf Of RS
> Sent: 08 August 2017 10:42
> To:
> Subject: Re: Playing BBC R3 FLAC files recorded by nightly VLC
> >From: Jim web
> >Sent: Monday, August 7, 2017 09:29
> >The first half dozen or so Proms I've recorded work fine. Occasional
> >errors about packets of unexpected length which seem to have no effect
> on
> >the recorded audio.
> >Some later recordings (but not the 'Ella and Dizzy' Prom) have begun
> >me 'HTTPS' errors which represent a missed chunk of audio data. I suspect
> >this *is* an 'overloading' issue but can't tell. In general these ruin
> >recording for me in terms of listening, but are useful for analysis
> >purposes. [1]
> For Prom 30 yesterday evening the 64 bit 31 July nightly build of VLC
> reported under its Statistics tab
> Lost 0 buffers
> Discarded (corrupted) 0
> Dropped (discontinued) 0
> There was something not quite right because it reported 180094 blocks
> Decoded and 90047 buffers Played when they should be the same after
> subtracting Lost.  It also reported 32 bits per sample when Mediainfo
> correctly reported 16.  Even so the figures are encouraging.
> Since the FLAC stream includes all the R3 output during the trial you can
> test whether a recent nightly build of VLC gives you better results than
> ffmpeg without risking loss of a Prom.  Of course it will not simulate the
> extra load during the Prom.
> Delay was 2min51s behind FM.
> _______________________________________________
> get_iplayer mailing list

get_iplayer mailing list

Reply via email to