No static at all
Join Date: Apr 2006
Location: uk
Posts: 880
Originally Posted by Lascaille
........................ in fact I believe we transmit from a site near Devon to Brazil.
Join Date: May 2001
Location: south of Cirencester, north of Lyneham
Age: 73
Posts: 1,248
'Near Devon' does depend on what you mean by near - to someone in the US or Oz, 'near' can be anything within a couple of hundred miles! The DRM transmissions come from the old VT Communications site at Woofferton, which is just south of Ludlow in Shropshire. VT communications is now owned by Babcock International Group.
Last edited by radeng; 21st Mar 2018 at 17:58. Reason: added words
Join Date: Jan 2015
Location: Mars
Posts: 72
Originally Posted by Tankertrashnav
Is it beyond the capabilities of the engineers to arrange things so that the time signal is received at the correct time on all systems?
Digital TV is a compressed signal.
Most of the compression is achieved 'temporally' i.e. by analysing how the frames are related in time.
The algorithms always start with a reference picture, that's called an I-frame. Your decoder receives the I-frame as a complete picture. Frame zero.
The next picture you see is generated by your decoder from what is basically an instruction list. The basic concept is that the i-frame (frame zero) is divided into a checkerboard of squares, with a separate 'transform' being applied to each square. A transform can be simple angular rotation, translation (sliding), brightness changes, colour changes, 3d-based changes (tilting into or out of the frame) all of which can be combined. The transform list is called a p-frame, because it's a frame that was 'predicted' forwards in time. A p-frame is in general at least 10x less data than an i-frame.
You can see how this easily encodes the natural changes associated with video - the picture changes associated with pans, sweeps, fades and zooms can be encoded almost perfectly by transforms.
Earlier systems used only i-frames and p-frames. Modern systems introduced b-frames. A b-frame is basically a p-frame with the ability to take source data from a wider range of frames, including later frames.
They're a requirement to efficiently encode scenes where new data gradually enters the scene, such as scene-to-scene dissolves, or a windowblind being opened onto a view.
To render a b-frame the decoder must have the source data. The source data could be from a future frame. How can we ensure the decoder has it?
Enter the concept of the group of pictures.
Each group of pictures is self-sufficient. It must contain at least one i-frame, so the b- and p- frames have something to work from. The i-frame doesn't have to be the first frame displayed, but it does have to be the first frame sent. The p- and b- frames follow in dependent order - first those that reference only the i-frames, then those that reference the 'first generation' p- or b-frames, then those that reference the 'second generation' and so on and suchlike.
The typical GOP for high quality broadcast services is 15-25 frames.
The encoder, similarly, has to create the GOP as a unit. It's also got to analyse the 15 or so frames it has in memory to work out which contains the most data that features in other frames (to make the i-frame), to determine the motion vectors and transforms, to decide whether to make a b- or a p- frame... Phew!
There's your delay.
Last edited by Lascaille; 21st Mar 2018 at 21:28.
Join Date: Nov 2000
Location: Cambridge, England, EU
Posts: 3,431
Originally Posted by Lascaille
It's the intrinsic nature of the system, unfortunately.
The picture/sound can be sent out ahead of time, and there could be a clock in the protocol, with a minimum buffering memory capability as part of the spec, so that when the clock says "it's ten o'clock" the radio or TV can play exactly what it should be playing at ten o'clock 'cos it's been buffering it for a second or whatever's needed. Obviously doesn't work for Big Ben live, but does work for pips or recorded bongs.
Join Date: Jan 2015
Location: Mars
Posts: 72
Originally Posted by Gertrude the Wombat
Only if you don't apply brain when defining the protocol.
The picture/sound can be sent out ahead of time, and there could be a clock in the protocol, with a minimum buffering memory capability as part of the spec, so that when the clock says "it's ten o'clock" the radio or TV can play exactly what it should be playing at ten o'clock 'cos it's been buffering it for a second or whatever's needed. Obviously doesn't work for Big Ben live, but does work for pips or recorded bongs.
The picture/sound can be sent out ahead of time, and there could be a clock in the protocol, with a minimum buffering memory capability as part of the spec, so that when the clock says "it's ten o'clock" the radio or TV can play exactly what it should be playing at ten o'clock 'cos it's been buffering it for a second or whatever's needed. Obviously doesn't work for Big Ben live, but does work for pips or recorded bongs.
Join Date: Jan 2015
Location: Mars
Posts: 72
Originally Posted by Gertrude the Wombat
BBC don't use it for the pips.
Join Date: Nov 2000
Location: Cambridge, England, EU
Posts: 3,431
Originally Posted by Lascaille
You do know that if your 'locally generated pips' thing was implemented then you'd have the locally generated pips interrupting the broadcast and being either followed or preceded by the 'studio' pips, right?
Join Date: Apr 2008
Location: Out in the sticks in DE56
Age: 82
Posts: 553
Originally Posted by Gertrude the Wombat
No, I'm suggesting that the broadcast is transmitted early and the timing signal is used to play it at the correct time.
Join Date: Jan 2015
Location: Mars
Posts: 72
Originally Posted by Gertrude the Wombat
No, I'm suggesting that the broadcast is transmitted early and the timing signal is used to play it at the correct time.
Oh I read back and saw more detail, did you edit?
You'd lose whatever would have been played just before that point, as your radio would have to abandon it in order to skip forwards and sync up. Could be avoidable by leaving a 10 second 'blank space' just before the top of every hour.
Join Date: Oct 2002
Location: West Wiltshire, UK
Age: 68
Posts: 390
DAB, like digital terrestrial TV, seems unbelievably sensitive to interference, and often just shuts off when there is the slightest bit of it. I have DAB in the car and it's the lack of "graceful degradation" that makes it unusable around here. FM may get a bit of additional background noise in a poor signal area, but it's usually not enough to stop you listening to the radio OK. DAB just goes silent the moment there is the slightest bit of interference or weakening of the signal, and will often stay silent for tens of seconds, maybe even minutes.
If DAB could be engineered to degrade gracefully then I think it'd be a great deal better than it is. I don't mind a bit of increased background noise for a short time, but can't stand just having the thing go silent, as that often means missing key parts of what I was listening to, which is the main reason I stick with FM in the car.
If DAB could be engineered to degrade gracefully then I think it'd be a great deal better than it is. I don't mind a bit of increased background noise for a short time, but can't stand just having the thing go silent, as that often means missing key parts of what I was listening to, which is the main reason I stick with FM in the car.
Join Date: Aug 1999
Location: Hyeres, France
Posts: 1
Maybe it's the DAB radio which we had, although more likely it's our age and the condition of my hearing, but I always find that although DAB transmissions are excellent if the signal is also excellent, the stereo seperation when listening through headphones is still fairly poor compared to a strong FM signal.
Like I said earlier, I now find the best way to listen to radio is by using an old LapTop which has an upgraded sound card ( cost me about € 85, fitted ) which is connected into my hi-fi system ( about € 1000 worth ) and it gives me superb quality sound for 000s of stations via the internet - not just those that broadcast on the local FM transmitter.
Although some stations are only streaming at 64kbps, that's still more than OK for speech such as BBC4, or in our case France Info. But for music stations streaming at 128kbps and 256kbps, the sound quality makes even FM sound like listening to Radio Luxemburg 208 on my little transistor radio as a teenager in 60s.
Add on the option of sites like Spotify for specific artists or music, and stand-alone radios are probably already obsolete.
Like I said earlier, I now find the best way to listen to radio is by using an old LapTop which has an upgraded sound card ( cost me about € 85, fitted ) which is connected into my hi-fi system ( about € 1000 worth ) and it gives me superb quality sound for 000s of stations via the internet - not just those that broadcast on the local FM transmitter.
Although some stations are only streaming at 64kbps, that's still more than OK for speech such as BBC4, or in our case France Info. But for music stations streaming at 128kbps and 256kbps, the sound quality makes even FM sound like listening to Radio Luxemburg 208 on my little transistor radio as a teenager in 60s.
Add on the option of sites like Spotify for specific artists or music, and stand-alone radios are probably already obsolete.
Join Date: Nov 2000
Location: Cambridge, England, EU
Posts: 3,431
Originally Posted by Lascaille
You'd lose whatever would have been played just before that point, as your radio would have to abandon it in order to skip forwards and sync up. Could be avoidable by leaving a 10 second 'blank space' just before the top of every hour.
Join Date: Feb 2007
Location: England
Posts: 356
Originally Posted by Gertrude the Wombat
No, because you'd transmit everything a couple of seconds earlier on digital. The entire channel, all day.
Join Date: Feb 2007
Location: England
Posts: 356
Originally Posted by jimtherev
Not totally sure that would work. ISTR that my older PURE Digital radio and a newer one were not quite synchronised - different decoder maybe? So I came to the conclusion that the delay was generated both at the TX and RX.
And incidentally the time signal is also delayed on FM broadcasts to some extent, because the distribution network is also a digital multiplex.
