MPEG Streamclip, "Headed MPEG"s & the mystery of the missing

[daffo2]

Hi guys,

I recently purchased an EyeTV Diversity (which has been fantastic!). I would now like to archive some of my Freeview recordings to an external hard disk...

Since I'm editing out advert breaks, I decided to try opening up my EyeTV files in MPEG Streamclip and then fix any timecode breaks. Great! I then chose "File" --> "Convert to Headed MPEG...". Now something really strange happened -- the resulting file (which, as far as I can tell, was NOT re-encoded, and which I will now refer to as the "MPEG Streamclip" version) turned out to be roughly 1GB smaller than the original file!! I thought that I must have done something wrong (or that the conversion must have failed), so I opened both files in VLC to do a side-by-side comparison. There was no noticeable loss in quality -- even by my (highly critical) eyes, both files were indistinguishable.

So, just to re-cap: the original (EyeTV) file is 2.33GB, and MPEG Streamclip's Headed MPEG file is 1.33GB. Both MPEG's are MPEG-2 video @ 544 x 576, 25fps, with MPEG-1 audio (Stereo, 48000 Hz, 192 kbps). Apart from the 1GB discrepancy in file-size, they are essentially identical!

I find this (i) mystifying, and (ii) slightly worrying. Don't get me wrong, I'm very happy to have saved a gigabyte of space... but where did it go??

I would really like to know what happened to the missing gigabyte. Surely the original broadcast didn't contain 1GB of metadata (or whatever). What happens when converting to a Headed MPEG? Is any information lost? Is there any explanation for this dramatic saving in space?

I would just hate to archive my EyeTV recordings only to discover that I've ended up with inferior files. But if the EyeTV versions contain a lot of redundant data then that's great news!

If you need me to provide any further information, I'll be happy to accommodate.

Many thanks for any help you can provide!

[ffooky]

I had a similar experience and can confirm that there really is a great deal of extraneous material in an EyeTV recording and an unre-encoded file extracted from one will be very significantly smaller.

[daffo2]

Hi ffooky. Thanks for bringing that other thread to my attention -- I see you really did your homework back then!!

I wonder if that redundant data serves any kind of purpose (and if not, what's it doing there in the first place?). I guess we might never know the answer, but at least we do know that it's safe to discard it without any ill-effects.

Thanks for all of your help!

[ffooky]

No worries. It does seem like a lot of excess but I'd guess it's stuff that EyeTV adds rather than being part of the transmission, though who knows ?

[mhar4]

I wonder if that redundant data serves any kind of purpose (and if not, what's it doing there in the first place?). I guess we might never know the answer, but at least we do know that it's safe to discard it without any ill-effects.

There is a large amount of additional data with DVB-T broadcasts, i.e. Freeview. Most obvious and potentially useful is subtitle data, and sometimes multiple audio streams. Also, when EyeTV exports a recording, it also strips out a lot of data. With subtitles, I have been able to create text-searchable h.264 Quicktime movies from broadcasts such as news programs, so you enter a keyword and the movie jumps to whereever that appears in the video. Very neat. The way to access all the additional data is with the Java application ProjectX.

[Herve]

an unre-encoded file extracted from one will be very significantly smaller.

MPSC only handles one video stream, one audio stream and no subtitle.
The new beta version (one moth ago?) handles multiple audios streams (so if you want and with this version, your resulting converted file will not be so small )

bye