Many recordings have wrong synopsis

Black Hole said:
Four seconds is unacceptably late? I don't think AR was ever intended as a mechanism to make transcription copies of broadcast programmes. This seems terribly fussy.
Click to expand...

How did the OP know one started four seconds late, apart from the clear problem with the Channel 4 all of the test recordings started recording before the opening titles of the actual programme.
 
The BBC have further reduced the bitrate from about 7Mbps see Episode of Dr Who

General
ID : 1 (0x1)
Complete name : E:\DrWho\Doctor Who_Ep01.ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 1.41 GiB
Duration : 47mn 39s
Overall bit rate mode : Variable
Overall bit rate : 4 247 Kbps

Video
ID : 5400 (0x1518)
Menu ID : 6941 (0x1B1D)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : 27
Duration : 47mn 39s
Bit rate : 3 424 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : MBAFF
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.066
Stream size : 1.14 GiB (81%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio #1
ID : 5401 (0x1519)
Menu ID : 6941 (0x1B1D)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 6
Duration : 47mn 39s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -1s 34ms
Stream size : 131 MiB (9%)
Language : English

Audio #2
ID : 5402 (0x151A)
Menu ID : 6941 (0x1B1D)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 3
Duration : 47mn 39s
Bit rate mode : Constant
Bit rate : 256 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -1s 2ms
Stream size : 87.3 MiB (6%)
Language : nar

Text #1
ID : 5403 (0x151B)-888
Menu ID : 6941 (0x1B1D)
Format : Teletext
Language : English

Text #2
ID : 5404 (0x151C)
Menu ID : 6941 (0x1B1D)
Format : DVB Subtitle
Codec ID : 6
Duration : 47mn 35s
Delay relative to video : 4s 485ms
Language : English
 
grahamlthompson said:
Pardon 7 Mbps is 7 Megabits per second. Divide by 8 to get Megabytes per second. 7 MBps would be 7 Megabytes per second. Sorry it's your replay that is nonsense. b is bit, B is Byte.
Click to expand...
But you said
BBC -HD uses about 7Mbps for it's HD service. In rough terms that's about 7/8 Megabytes/Second.
Click to expand...
I don't understand the correlation between the two posts, as they seem to contradict each other. Can you enlarge on this please for a dimwit.
 
Trev said:
But you said I don't understand the correlation between the two posts, as they seem to contradict each other. Can you enlarge on this please for a dimwit.
Click to expand...

7/8 is 7 over 8 or 0.875 MBps

In rough terms that's about 7/8 Megabytes/Second. (One byte is 8 bits). It's rough because extra parity bits will be included in the data stream. And 1000 is used instead of 1024 to convert. It's good enough to produce a valid comparison.
 
Last edited:
I think the problem was a mis-reading of the "7/8 Mbps" as meaning "seven or eight" rather than "seven eighths". Writing "1.75 Mbps" would have been clearer (but then it is possible to argue about what "M" means exactly).
 
Black Hole said:
I think the problem was a mis-reading of the "7/8 Mbps" as meaning "seven or eight" rather than "seven eighths".
Click to expand...
Yes, that was my problem. I actualy interpreted it as 7 or 8 (allowing for 1024 v 1000) and even with multiple re-readings of GLT's post, I didn't twig:oops:
Writing "1.75 Mbps" would have been clearer
Click to expand...
Agreed. Awesome explanation BH :) Except that 1.75 MBs would have been even better:geek:
 
Black Hole said:
I think the problem was a mis-reading of the "7/8 Mbps" as meaning "seven or eight" rather than "seven eighths". Writing "1.75 Mbps" would have been clearer (but then it is possible to argue about what "M" means exactly).
Click to expand...

I thought the comment in brackets immediately after made it clear what I meant. In hindsight it would have been clearer to add the conversion to MBps. Coming from a basic programming background / is always used for division.
 
Black Hole said:
I think the problem was a mis-reading of the "7/8 Mbps" as meaning "seven or eight" rather than "seven eighths".
Click to expand...
Yes, that was indeed the case. Apologies, but not just me it seems.
Writing "1.75 Mbps" would have been clearer (but then it is possible to argue about what "M" means exactly).
Click to expand...
I don't know where the 1.75 has suddenly come from.
 
Black Hole said:
Four seconds is unacceptably late? I don't think AR was ever intended as a mechanism to make transcription copies of broadcast programmes. This seems terribly fussy.
Click to expand...
I thought the entire premise with Accurate Recording was that the broadcaster sends a signal exactly when the program starts and stops. If this signal can be several seconds late/early you can miss crucial parts of the recording, which in my view invalidates the entire concept. And if the synopsis can be incorrect anyway with AR (which was the reason for me looking into AR in the first place, trying to see whether this would fix the many incorrect synopsises), this doesn't solve my original problem.

Yes I'm terribly fussy about not missing anything. So I'll be switching back to padding and finishing my shell script that'll fix incorrect synopsises on recorded programs.
 
Trev said:
And miss a 'vital' recording when MoTD overruns?
Click to expand...
It's extremely rare that my recordings are affected by programs running late. I would say less than 1% - a lot less than the 12.5% failure rate I experienced with AR last week.
 
grahamlthompson said:
How did the OP know one started four seconds late, apart from the clear problem with the Channel 4 all of the test recordings started recording before the opening titles of the actual programme.
Click to expand...
By comparing with the same program on 4oD or whatever they call it this month.
 
Channel 4 seem to be making a rights dogs dinner at the moment. AR set for CH 4 HD on HDR FOX T2 Sunday 29th Guy Martin: Last Flight of the Vulcan Bomber. (19:30 - 21:00). Started recording 2 mins early but stopped recording after 62 mins. I doubt padding would have saved this one.
 
grahamlthompson said:
Channel 4 seem to be making a rights dogs dinner at the moment. AR set for CH 4 HD on HDR FOX T2 Sunday 29th Guy Martin: Last Flight of the Vulcan Bomber. (19:30 - 21:00). Started recording 2 mins early but stopped recording after 62 mins. I doubt padding would have saved this one.
Click to expand...
For that recording on my Foxsat HDR I have a start time of 19:58 with an end time of 21:00, so it started 28 minutes into the programme but ended on time. Regardless, I must agree Graham, a total cock up by Channel 4. However, all is not lost as it's being repeated twice on 4seven this week. Hopefully I can still record the HD version using my HDR Fox T2 instead, don't know whether to risk using AR again though. :confused:
 
Last edited:
You must log in or register to reply here.
Back
Top