Patrick Mackin wrote:

> I have noticed a potential bug in playing back radio channels.  The
> playback time of recorded radio channels is inflated by almost 40%. 
> This has been confirmed on four North American satellites on three
> different providers.  The reported time for a 10 minute recording will
> consistently appear as 13:47.  Some have hypothesized the problem comes
> from the fact that vdr's timers are based on video frame rates, which of
> course don't exist on radio channels.
> World Radio Network (wrn.org <http://www.org>) is one example, and is
> broadcast on satellite worldwide, so perhaps this can be confirmed on
> other sats outside NA.  The timing problem makes it very difficult to
> skip commercials or "top of the hour" news reports or to skip between
> programming that occurs, for example, every 30 minutes.  In America, I
> have made observations on Telstar5.  In Europe, you can try Sky Digital
> (Eurobird 1, 28.5E) or Eutelsat Hotbird 6 (13E) or Afristar (paytv).
> Additionally, there appears to be a problem that some have reported
> with certain NA provider varying the video frame rate, causing
> *underreporting* of playback time, which would seem to confirm this
> hypothesis.

VDR derives the playback times for a recording  by a hard coded
relationship from the number of an index entry in the recording's index
file (see recording.h, FRAMESPERSEC). The default relationship of 25
frames per second doesn't suit to NTSC broadcasts with 30 frames per
second, so VDR reports a larger playtime than the recording will
actually play.

Regarding radio recordings, the biggest problem is, that there is no
video stream which would generate an index entry every 40 ms (for the
default value of 25 frames per second). Since the introduction of my
cAudioRepacker, things got even worse but more predictable: now every
audio frame generates an index entry.

But as the duration of an audio frame depends on bitrate, sample rate,
and further audio stream parameters, it typically isn't 40 ms, but
should be constant until the stream parameters change. That's why you
get a consistent error for playback times of radio recordings.

I've already thought about patching VDR that it determines FRAMESPERSEC
dynamically by looking at the duration of the first frame of a
recording, but I've dropped that idea as there are channels which
provide more than one radio stream. So, to fix this issue I'd have to
fix cRemux to not generate an index entry for every audio frame. I have
an idea now how to achieve this -- don't know why it didn't come into my
mind earlier already ;-)

Dipl.-Inform. (FH) Reinhard Nissl

vdr mailing list

Reply via email to