<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_12_17_187248</id>
	<title>BBC Lowers HDTV Bitrate; Users Notice</title>
	<author>timothy</author>
	<datestamp>1261073340000</datestamp>
	<htmltext>aws910 writes <i>"According to an article on the BBC website, BBC HD <a href="http://news.bbc.co.uk/2/hi/technology/8415636.stm">lowered the bitrate of their broadcasts by almost 50\%</a> and are surprised that users noticed.  From the article: 'The replacement encoders work at a bitrate of 9.7Mbps (megabits per second), while their predecessors worked at 16Mbps, the standard for other broadcasters.'  The BBC claims 'We did extensive testing on the new encoders which showed that they could produce pictures at the same or even better quality than the old encoders ...'  I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?"</i></htmltext>
<tokenext>aws910 writes " According to an article on the BBC website , BBC HD lowered the bitrate of their broadcasts by almost 50 \ % and are surprised that users noticed .
From the article : 'The replacement encoders work at a bitrate of 9.7Mbps ( megabits per second ) , while their predecessors worked at 16Mbps , the standard for other broadcasters .
' The BBC claims 'We did extensive testing on the new encoders which showed that they could produce pictures at the same or even better quality than the old encoders ... ' I got a good laugh off of this , but is it really possible to get better quality from a lower bitrate ?
"</tokentext>
<sentencetext>aws910 writes "According to an article on the BBC website, BBC HD lowered the bitrate of their broadcasts by almost 50\% and are surprised that users noticed.
From the article: 'The replacement encoders work at a bitrate of 9.7Mbps (megabits per second), while their predecessors worked at 16Mbps, the standard for other broadcasters.
'  The BBC claims 'We did extensive testing on the new encoders which showed that they could produce pictures at the same or even better quality than the old encoders ...'  I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476398</id>
	<title>Re:Yes</title>
	<author>Albanach</author>
	<datestamp>1261077960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It would also be quite remarkable to see better quality compared to any other modern encoding while reducing bitrate by 50\%.</p></htmltext>
<tokenext>It would also be quite remarkable to see better quality compared to any other modern encoding while reducing bitrate by 50 \ % .</tokentext>
<sentencetext>It would also be quite remarkable to see better quality compared to any other modern encoding while reducing bitrate by 50\%.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476560</id>
	<title>Ummm ....</title>
	<author>gstoddart</author>
	<datestamp>1261078560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>In her blog post, Ms Nagler said that the services was created to be at its best for "typical viewing set ups" and that user groups with standard equipment were happy with the service.</p></div></blockquote><p>Is she saying that they've optimized their HD for people without HD screens, or am I just confused?</p><p>It really does sound like they're trying to sell something which isn't HD, but gets sold as if it is.  Strange.  "<em>Now, to server you better, we are open fewer hours.</em>"</p><p>Cheers</p></div>
	</htmltext>
<tokenext>In her blog post , Ms Nagler said that the services was created to be at its best for " typical viewing set ups " and that user groups with standard equipment were happy with the service.Is she saying that they 've optimized their HD for people without HD screens , or am I just confused ? It really does sound like they 're trying to sell something which is n't HD , but gets sold as if it is .
Strange. " Now , to server you better , we are open fewer hours .
" Cheers</tokentext>
<sentencetext>In her blog post, Ms Nagler said that the services was created to be at its best for "typical viewing set ups" and that user groups with standard equipment were happy with the service.Is she saying that they've optimized their HD for people without HD screens, or am I just confused?It really does sound like they're trying to sell something which isn't HD, but gets sold as if it is.
Strange.  "Now, to server you better, we are open fewer hours.
"Cheers
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479004</id>
	<title>yes you can</title>
	<author>johnrpenner</author>
	<datestamp>1261044180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>i did some a-b comparisons a while ago.. i was using handbrake.. CBR 700kbs.. between<nobr> <wbr></nobr>.mpeg and h264.. the h264 close-up pixel quality was superiour to the pixels of the mpeg clip.. whose file size was also larger..  h264 was so much better, in fact, that i vowed never to encode another film as mpeg again.. the cost however, is more processor usage.. mpeg can deliver a stutter-free picture on lower Mhz machines.. h264 gives better results &amp; smaller size -- but requires more horsepower to interpret to the screen..</p><p>2cents from toronto island<nobr> <wbr></nobr>:D<br>jp</p></htmltext>
<tokenext>i did some a-b comparisons a while ago.. i was using handbrake.. CBR 700kbs.. between .mpeg and h264.. the h264 close-up pixel quality was superiour to the pixels of the mpeg clip.. whose file size was also larger.. h264 was so much better , in fact , that i vowed never to encode another film as mpeg again.. the cost however , is more processor usage.. mpeg can deliver a stutter-free picture on lower Mhz machines.. h264 gives better results &amp; smaller size -- but requires more horsepower to interpret to the screen..2cents from toronto island : Djp</tokentext>
<sentencetext>i did some a-b comparisons a while ago.. i was using handbrake.. CBR 700kbs.. between .mpeg and h264.. the h264 close-up pixel quality was superiour to the pixels of the mpeg clip.. whose file size was also larger..  h264 was so much better, in fact, that i vowed never to encode another film as mpeg again.. the cost however, is more processor usage.. mpeg can deliver a stutter-free picture on lower Mhz machines.. h264 gives better results &amp; smaller size -- but requires more horsepower to interpret to the screen..2cents from toronto island :Djp</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476224</id>
	<title>It is absolutely possible</title>
	<author>Anonymous</author>
	<datestamp>1261077300000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Bitrate is only part of the equation -- the H.264 spec allows for a number of different ways to compress video, and it's up to the encoder to find out which is best for your video.  Even in the same encoder, you can tweak dozens of settings in ways that dramatically change output quality -- usually a trade off between time and size.</p><p>x264 has beat every commercial encoder out there -- in some cases, on a level that would indeed render higher quality with half the bitrate.</p></htmltext>
<tokenext>Bitrate is only part of the equation -- the H.264 spec allows for a number of different ways to compress video , and it 's up to the encoder to find out which is best for your video .
Even in the same encoder , you can tweak dozens of settings in ways that dramatically change output quality -- usually a trade off between time and size.x264 has beat every commercial encoder out there -- in some cases , on a level that would indeed render higher quality with half the bitrate .</tokentext>
<sentencetext>Bitrate is only part of the equation -- the H.264 spec allows for a number of different ways to compress video, and it's up to the encoder to find out which is best for your video.
Even in the same encoder, you can tweak dozens of settings in ways that dramatically change output quality -- usually a trade off between time and size.x264 has beat every commercial encoder out there -- in some cases, on a level that would indeed render higher quality with half the bitrate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479018</id>
	<title>Re:Yes</title>
	<author>pete-classic</author>
	<datestamp>1261044180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Generally, "better" compression [...] requires a lot more power to encode and often some more power to decode. [...] But their customers' television sets might not have the horsepower to decode it at full quality.</p></div></blockquote><p>Your first statement is true.  And it is interesting to note that the "power" requirements generally increase exponentially on the encode side, but <em>linearly</em> on the decode side.  This is due to the intentionally asymmetric design of video codecs of interest.</p><p>Your second statement makes less sense.  There may be some nuance here that I'm unaware of, but generally you are able to successfully decode a video frame or you aren't.  You can't fairly characterize a failure to decode a frame as reduced quality.</p><p>The good news is that profiles are rigidly defined, so this <em>should</em> never happen.</p><blockquote><div><p>It's also possible that, by compressing the video stream into a denser compression method, signal loss is having a greater effect than it did with the old compression method.</p></div></blockquote><p>Uncorrectable blocks <em>invariably</em> results in "macroblocking" (or "tiling") artifacts.  Since the same number of frames are being transmitted per second, line errors of a given duration will affect the same number of frames.</p><p>The determining factor here is the interleaver depth, not the bits per frame.</p><p>-Peter</p><p>-Peter</p></div>
	</htmltext>
<tokenext>Generally , " better " compression [ ... ] requires a lot more power to encode and often some more power to decode .
[ ... ] But their customers ' television sets might not have the horsepower to decode it at full quality.Your first statement is true .
And it is interesting to note that the " power " requirements generally increase exponentially on the encode side , but linearly on the decode side .
This is due to the intentionally asymmetric design of video codecs of interest.Your second statement makes less sense .
There may be some nuance here that I 'm unaware of , but generally you are able to successfully decode a video frame or you are n't .
You ca n't fairly characterize a failure to decode a frame as reduced quality.The good news is that profiles are rigidly defined , so this should never happen.It 's also possible that , by compressing the video stream into a denser compression method , signal loss is having a greater effect than it did with the old compression method.Uncorrectable blocks invariably results in " macroblocking " ( or " tiling " ) artifacts .
Since the same number of frames are being transmitted per second , line errors of a given duration will affect the same number of frames.The determining factor here is the interleaver depth , not the bits per frame.-Peter-Peter</tokentext>
<sentencetext>Generally, "better" compression [...] requires a lot more power to encode and often some more power to decode.
[...] But their customers' television sets might not have the horsepower to decode it at full quality.Your first statement is true.
And it is interesting to note that the "power" requirements generally increase exponentially on the encode side, but linearly on the decode side.
This is due to the intentionally asymmetric design of video codecs of interest.Your second statement makes less sense.
There may be some nuance here that I'm unaware of, but generally you are able to successfully decode a video frame or you aren't.
You can't fairly characterize a failure to decode a frame as reduced quality.The good news is that profiles are rigidly defined, so this should never happen.It's also possible that, by compressing the video stream into a denser compression method, signal loss is having a greater effect than it did with the old compression method.Uncorrectable blocks invariably results in "macroblocking" (or "tiling") artifacts.
Since the same number of frames are being transmitted per second, line errors of a given duration will affect the same number of frames.The determining factor here is the interleaver depth, not the bits per frame.-Peter-Peter
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564</id>
	<title>Re:Summary rounding error</title>
	<author>DragonWriter</author>
	<datestamp>1261078560000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>Nitpick: So 39\% is "almost 50\%"??</p></div> </blockquote><p>Yes, its almost 50\% -- if you are, e.g., relating it to the nearest 25\%. (Rounding it to the nearest 25\% it would be just plain 50\%, not "almost 50\%".)</p><blockquote><div><p>I would have called that "almost 40\%".</p></div> </blockquote><p>Its also almost 40\% -- if you are, e.g., relating it to the nearest 10\% (or 5\% or 2\%). And, in fact, 6.3/16 is also "almost 39.5\%" if you are relating it to nearest 0.5\%, and "just over 39\%" if you are relating it to the nearest 1\%.</p><p>"Almost" means you are giving an approximation (and the direction the value differs from the approximation), not an exact figure. There are infinite number of possible approximations for any given exact value. That something could be described as "almost 40\%" does not mean it cannot also be described as "almost 50\%" without any "rounding error", since "almost" does not specify the precision of the approximation being used.</p></div>
	</htmltext>
<tokenext>Nitpick : So 39 \ % is " almost 50 \ % " ? ?
Yes , its almost 50 \ % -- if you are , e.g. , relating it to the nearest 25 \ % .
( Rounding it to the nearest 25 \ % it would be just plain 50 \ % , not " almost 50 \ % " .
) I would have called that " almost 40 \ % " .
Its also almost 40 \ % -- if you are , e.g. , relating it to the nearest 10 \ % ( or 5 \ % or 2 \ % ) .
And , in fact , 6.3/16 is also " almost 39.5 \ % " if you are relating it to nearest 0.5 \ % , and " just over 39 \ % " if you are relating it to the nearest 1 \ % .
" Almost " means you are giving an approximation ( and the direction the value differs from the approximation ) , not an exact figure .
There are infinite number of possible approximations for any given exact value .
That something could be described as " almost 40 \ % " does not mean it can not also be described as " almost 50 \ % " without any " rounding error " , since " almost " does not specify the precision of the approximation being used .</tokentext>
<sentencetext>Nitpick: So 39\% is "almost 50\%"??
Yes, its almost 50\% -- if you are, e.g., relating it to the nearest 25\%.
(Rounding it to the nearest 25\% it would be just plain 50\%, not "almost 50\%".
)I would have called that "almost 40\%".
Its also almost 40\% -- if you are, e.g., relating it to the nearest 10\% (or 5\% or 2\%).
And, in fact, 6.3/16 is also "almost 39.5\%" if you are relating it to nearest 0.5\%, and "just over 39\%" if you are relating it to the nearest 1\%.
"Almost" means you are giving an approximation (and the direction the value differs from the approximation), not an exact figure.
There are infinite number of possible approximations for any given exact value.
That something could be described as "almost 40\%" does not mean it cannot also be described as "almost 50\%" without any "rounding error", since "almost" does not specify the precision of the approximation being used.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476540</id>
	<title>Sure!</title>
	<author>Anonymous</author>
	<datestamp>1261078500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just look at carbon... carbon alone without any compression isn't quite nice...<br>But COMPRESS it and you have something much higher in quality......<nobr> <wbr></nobr>;)</p></htmltext>
<tokenext>Just look at carbon... carbon alone without any compression is n't quite nice...But COMPRESS it and you have something much higher in quality...... ; )</tokentext>
<sentencetext>Just look at carbon... carbon alone without any compression isn't quite nice...But COMPRESS it and you have something much higher in quality...... ;)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578</id>
	<title>A better model beats higher bitrate every time</title>
	<author>Edgewize</author>
	<datestamp>1261078620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Lossy compression formats depend on an understanding of human perception.  Nobody has a perfect model of the human brain, and nobody has a perfect algorithm for deciding what data to keep and what data to throw away.</p><p>If you have a better model of human perception than your competitors, then your encoder will yield higher quality output.  If you spend 50\% of your bits on things that nobody will notice, and I spend 25\% of my bits on things that nobody will notice, then my 650kbps stream is going to look better than your 900kbps stream.</p><p>LAME did not win out as the MP3 encoder of choice just because it is free.  It won out because its psychoacoustic model yields better-sounding MP3s at 128kbps than its competitors managed at 160kbps or even 192kbps.</p></htmltext>
<tokenext>Lossy compression formats depend on an understanding of human perception .
Nobody has a perfect model of the human brain , and nobody has a perfect algorithm for deciding what data to keep and what data to throw away.If you have a better model of human perception than your competitors , then your encoder will yield higher quality output .
If you spend 50 \ % of your bits on things that nobody will notice , and I spend 25 \ % of my bits on things that nobody will notice , then my 650kbps stream is going to look better than your 900kbps stream.LAME did not win out as the MP3 encoder of choice just because it is free .
It won out because its psychoacoustic model yields better-sounding MP3s at 128kbps than its competitors managed at 160kbps or even 192kbps .</tokentext>
<sentencetext>Lossy compression formats depend on an understanding of human perception.
Nobody has a perfect model of the human brain, and nobody has a perfect algorithm for deciding what data to keep and what data to throw away.If you have a better model of human perception than your competitors, then your encoder will yield higher quality output.
If you spend 50\% of your bits on things that nobody will notice, and I spend 25\% of my bits on things that nobody will notice, then my 650kbps stream is going to look better than your 900kbps stream.LAME did not win out as the MP3 encoder of choice just because it is free.
It won out because its psychoacoustic model yields better-sounding MP3s at 128kbps than its competitors managed at 160kbps or even 192kbps.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30526260</id>
	<title>Re:Crap HD Quality</title>
	<author>CByrd17</author>
	<datestamp>1261509780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>For what it's worth, today's movies do not involve changing reels.  The reels are all spliced together by a projectionist when the movie arrives at a theater.  During this process the film becomes one giant "reel" that sits on a rotating platter and feeds through the projector to an identical platter that sits below the first one.

I know that it's off topic, but it's also a neat process!</htmltext>
<tokenext>For what it 's worth , today 's movies do not involve changing reels .
The reels are all spliced together by a projectionist when the movie arrives at a theater .
During this process the film becomes one giant " reel " that sits on a rotating platter and feeds through the projector to an identical platter that sits below the first one .
I know that it 's off topic , but it 's also a neat process !</tokentext>
<sentencetext>For what it's worth, today's movies do not involve changing reels.
The reels are all spliced together by a projectionist when the movie arrives at a theater.
During this process the film becomes one giant "reel" that sits on a rotating platter and feeds through the projector to an identical platter that sits below the first one.
I know that it's off topic, but it's also a neat process!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480440</id>
	<title>Re:Quite a bit left out</title>
	<author>lga</author>
	<datestamp>1261049640000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>They do expect everyone to get a new receiver.

Freeview HD has just started it's rollout, although no receivers will be available until next month. It uses H.264 and DVB-T2.</htmltext>
<tokenext>They do expect everyone to get a new receiver .
Freeview HD has just started it 's rollout , although no receivers will be available until next month .
It uses H.264 and DVB-T2 .</tokentext>
<sentencetext>They do expect everyone to get a new receiver.
Freeview HD has just started it's rollout, although no receivers will be available until next month.
It uses H.264 and DVB-T2.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476502</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476676</id>
	<title>Re:Yes</title>
	<author>MisterSquid</author>
	<datestamp>1261078920000</datestamp>
	<modclass>Troll</modclass>
	<modscore>0</modscore>
	<htmltext>I absolutely agree. In fact, this new technology I've patented has produced better than HD compression with <a href="http://bit.ly/videocodec" title="bit.ly">unparalleled image quality</a> [bit.ly]. Contact me if you're interested in licensing.</htmltext>
<tokenext>I absolutely agree .
In fact , this new technology I 've patented has produced better than HD compression with unparalleled image quality [ bit.ly ] .
Contact me if you 're interested in licensing .</tokentext>
<sentencetext>I absolutely agree.
In fact, this new technology I've patented has produced better than HD compression with unparalleled image quality [bit.ly].
Contact me if you're interested in licensing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478830</id>
	<title>Re:Focus group...</title>
	<author>jasonwc</author>
	<datestamp>1261043520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Well, on my Core i7/Core 2 Duo systems, running a variety of decodeds (ffdshow, MPC's internal decoder, and CoreAVC), and in fact every system I have used, that is the case.</p><p>If you want to check this, get the Blu-Ray source for Defiance, and I can send you an x264 encode of the first few minutes of the film - lower bitrate, but much higher CPU usage because of the settings used. In that case, the encode was also 4.1 but it used much more aggressive (higher quality) settings.</p></htmltext>
<tokenext>Well , on my Core i7/Core 2 Duo systems , running a variety of decodeds ( ffdshow , MPC 's internal decoder , and CoreAVC ) , and in fact every system I have used , that is the case.If you want to check this , get the Blu-Ray source for Defiance , and I can send you an x264 encode of the first few minutes of the film - lower bitrate , but much higher CPU usage because of the settings used .
In that case , the encode was also 4.1 but it used much more aggressive ( higher quality ) settings .</tokentext>
<sentencetext>Well, on my Core i7/Core 2 Duo systems, running a variety of decodeds (ffdshow, MPC's internal decoder, and CoreAVC), and in fact every system I have used, that is the case.If you want to check this, get the Blu-Ray source for Defiance, and I can send you an x264 encode of the first few minutes of the film - lower bitrate, but much higher CPU usage because of the settings used.
In that case, the encode was also 4.1 but it used much more aggressive (higher quality) settings.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477364</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476968</id>
	<title>Re:Their new algorithm?</title>
	<author>Anonymous</author>
	<datestamp>1261079940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Ahh, the good ol&rsquo; days... removing the nipples from the prons to save precious bandwidth over a dial-up connection...</p></htmltext>
<tokenext>Ahh , the good ol    days... removing the nipples from the prons to save precious bandwidth over a dial-up connection.. .</tokentext>
<sentencetext>Ahh, the good ol’ days... removing the nipples from the prons to save precious bandwidth over a dial-up connection...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476222</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482538</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261061820000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><p>+5 Internets</p></htmltext>
<tokenext>+ 5 Internets</tokentext>
<sentencetext>+5 Internets</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479052</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261044300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>True, but however smart the encoder is, it will have to deal with complex contents such as falling snow, reflections on water surface, confetti, etc where even the smartest of encoders fail like mpeg-2. In this case, the only thing that matters is bitrate, and with 9 mbps, yuk.</p></htmltext>
<tokenext>True , but however smart the encoder is , it will have to deal with complex contents such as falling snow , reflections on water surface , confetti , etc where even the smartest of encoders fail like mpeg-2 .
In this case , the only thing that matters is bitrate , and with 9 mbps , yuk .</tokentext>
<sentencetext>True, but however smart the encoder is, it will have to deal with complex contents such as falling snow, reflections on water surface, confetti, etc where even the smartest of encoders fail like mpeg-2.
In this case, the only thing that matters is bitrate, and with 9 mbps, yuk.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476330</id>
	<title>Still a way to go...</title>
	<author>TheRaven64</author>
	<datestamp>1261077720000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>For reference, the BBC HD content on iPlayer is 3.5Mb/s for 720p (no higher quality available).  9.7Mb/s is less than three times as much, so it probably won't be long before the streaming and broadcast signals are the same quality.</htmltext>
<tokenext>For reference , the BBC HD content on iPlayer is 3.5Mb/s for 720p ( no higher quality available ) .
9.7Mb/s is less than three times as much , so it probably wo n't be long before the streaming and broadcast signals are the same quality .</tokentext>
<sentencetext>For reference, the BBC HD content on iPlayer is 3.5Mb/s for 720p (no higher quality available).
9.7Mb/s is less than three times as much, so it probably won't be long before the streaming and broadcast signals are the same quality.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30491342</id>
	<title>I want to be completely honest about this</title>
	<author>Anonymous</author>
	<datestamp>1261167120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>If you find yourself nitpicking here, you need to question the usefulness of your life, and consider ending it.</htmltext>
<tokenext>If you find yourself nitpicking here , you need to question the usefulness of your life , and consider ending it .</tokentext>
<sentencetext>If you find yourself nitpicking here, you need to question the usefulness of your life, and consider ending it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476266</id>
	<title>less is more</title>
	<author>Anonymous</author>
	<datestamp>1261077480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>"<i>We did extensive testing on the new encoders which showed that they could produce pictures at the same or even better quality than the old encoders</i>"<br> <br>
I find this hard to believe, especially as there are already complaints in the iPlayer forum.</htmltext>
<tokenext>" We did extensive testing on the new encoders which showed that they could produce pictures at the same or even better quality than the old encoders " I find this hard to believe , especially as there are already complaints in the iPlayer forum .</tokentext>
<sentencetext>"We did extensive testing on the new encoders which showed that they could produce pictures at the same or even better quality than the old encoders" 
I find this hard to believe, especially as there are already complaints in the iPlayer forum.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480108</id>
	<title>Re:Crap HD Quality</title>
	<author>Anonymous</author>
	<datestamp>1261048320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The 'two little circles' are called cueing dots.</p><p>The syndrome you mention is called 'projectionist's panic'<br>and nearly anyone who's been a projectionist will jump<br>out of whatever reverie/universe s/he may be in with the<br>film to worry if he's missed the setup for the next reel.</p></htmltext>
<tokenext>The 'two little circles ' are called cueing dots.The syndrome you mention is called 'projectionist 's panic'and nearly anyone who 's been a projectionist will jumpout of whatever reverie/universe s/he may be in with thefilm to worry if he 's missed the setup for the next reel .</tokentext>
<sentencetext>The 'two little circles' are called cueing dots.The syndrome you mention is called 'projectionist's panic'and nearly anyone who's been a projectionist will jumpout of whatever reverie/universe s/he may be in with thefilm to worry if he's missed the setup for the next reel.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480162</id>
	<title>Re:A better model beats higher bitrate every time</title>
	<author>TheGratefulNet</author>
	<datestamp>1261048560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>yes, the model matters more.</p><p>back in 98 when mp3 was still kinda new, I ponied up some serious scratch for the fraun. mp3 encoder ($200 for the linux a.out version).  back then, nothing could touch it for 128k encodes.  lame was lame and nothing was good until 192 or even 256.  I encoded all my discs at 128k and it was pretty good (still is).  I 'invested' in that binary-only encoder as I would a piece of stereo gear.  it performed higher than anything else out there.  I still can get that nasty a.out thing to work on freebsd with linux emulation (but not on natural linux; figure THAT one out!).  and while its slow, its still useful to have high quality 128k encodes (for smaller flash based players).  for home files, I now use flac but 128k for mp3 makes good sense as a non-flac alternative.</p><p>just as an example of how the codec matters more than raw bitrate.</p></htmltext>
<tokenext>yes , the model matters more.back in 98 when mp3 was still kinda new , I ponied up some serious scratch for the fraun .
mp3 encoder ( $ 200 for the linux a.out version ) .
back then , nothing could touch it for 128k encodes .
lame was lame and nothing was good until 192 or even 256 .
I encoded all my discs at 128k and it was pretty good ( still is ) .
I 'invested ' in that binary-only encoder as I would a piece of stereo gear .
it performed higher than anything else out there .
I still can get that nasty a.out thing to work on freebsd with linux emulation ( but not on natural linux ; figure THAT one out ! ) .
and while its slow , its still useful to have high quality 128k encodes ( for smaller flash based players ) .
for home files , I now use flac but 128k for mp3 makes good sense as a non-flac alternative.just as an example of how the codec matters more than raw bitrate .</tokentext>
<sentencetext>yes, the model matters more.back in 98 when mp3 was still kinda new, I ponied up some serious scratch for the fraun.
mp3 encoder ($200 for the linux a.out version).
back then, nothing could touch it for 128k encodes.
lame was lame and nothing was good until 192 or even 256.
I encoded all my discs at 128k and it was pretty good (still is).
I 'invested' in that binary-only encoder as I would a piece of stereo gear.
it performed higher than anything else out there.
I still can get that nasty a.out thing to work on freebsd with linux emulation (but not on natural linux; figure THAT one out!).
and while its slow, its still useful to have high quality 128k encodes (for smaller flash based players).
for home files, I now use flac but 128k for mp3 makes good sense as a non-flac alternative.just as an example of how the codec matters more than raw bitrate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477392</id>
	<title>Re:Of course it is possible</title>
	<author>Rui del-Negro</author>
	<datestamp>1261081500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That second sentence makes absolutely no sense.</p></htmltext>
<tokenext>That second sentence makes absolutely no sense .</tokentext>
<sentencetext>That second sentence makes absolutely no sense.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476190</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476382</id>
	<title>Re:Yes</title>
	<author>Fantom42</author>
	<datestamp>1261077960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?</p><p><div class="quote"><p>Sure, if you also switch to a better codec, such as using H.264 instead of MPEG-2. However, I don't think that's what's happening in this case</p></div></div><p>Just to amplify what has been said here a few times, yes it is possible, and not only from changing codecs.  H.264 supports many optional features that are not implemented in all decoders, and these features can have an effect on quality.  Use of a variable bit rate vice a constant bitrate can also increase quality and decrease bandwidth needs, at the cost of requiring some bursting capability or buffering to accomodate the variation.  Also, there are tricks that can be played with dark and light tone masking to increase the compressibility of a video stream, and any number of other preprocessing tricks that people use.</p><p>The reason I bring up this point, is it might be that they tweaked the parameters to achieve a lower bitrate, and thought they weren't sacraficing quality, but that different viewing devices, or different people, were able to notice a change in quality that the study group they used was not.  Point being that these guys may not have been as stupid as people are making them out to be, but just designed a poor test.  Video compression and judging output quality is really complicated and depends on a lot of factors.  It could be they just missed some of those factors when they tweaked the encoding algorithm.</p></div>
	</htmltext>
<tokenext>I got a good laugh off of this , but is it really possible to get better quality from a lower bitrate ? Sure , if you also switch to a better codec , such as using H.264 instead of MPEG-2 .
However , I do n't think that 's what 's happening in this caseJust to amplify what has been said here a few times , yes it is possible , and not only from changing codecs .
H.264 supports many optional features that are not implemented in all decoders , and these features can have an effect on quality .
Use of a variable bit rate vice a constant bitrate can also increase quality and decrease bandwidth needs , at the cost of requiring some bursting capability or buffering to accomodate the variation .
Also , there are tricks that can be played with dark and light tone masking to increase the compressibility of a video stream , and any number of other preprocessing tricks that people use.The reason I bring up this point , is it might be that they tweaked the parameters to achieve a lower bitrate , and thought they were n't sacraficing quality , but that different viewing devices , or different people , were able to notice a change in quality that the study group they used was not .
Point being that these guys may not have been as stupid as people are making them out to be , but just designed a poor test .
Video compression and judging output quality is really complicated and depends on a lot of factors .
It could be they just missed some of those factors when they tweaked the encoding algorithm .</tokentext>
<sentencetext>I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?Sure, if you also switch to a better codec, such as using H.264 instead of MPEG-2.
However, I don't think that's what's happening in this caseJust to amplify what has been said here a few times, yes it is possible, and not only from changing codecs.
H.264 supports many optional features that are not implemented in all decoders, and these features can have an effect on quality.
Use of a variable bit rate vice a constant bitrate can also increase quality and decrease bandwidth needs, at the cost of requiring some bursting capability or buffering to accomodate the variation.
Also, there are tricks that can be played with dark and light tone masking to increase the compressibility of a video stream, and any number of other preprocessing tricks that people use.The reason I bring up this point, is it might be that they tweaked the parameters to achieve a lower bitrate, and thought they weren't sacraficing quality, but that different viewing devices, or different people, were able to notice a change in quality that the study group they used was not.
Point being that these guys may not have been as stupid as people are making them out to be, but just designed a poor test.
Video compression and judging output quality is really complicated and depends on a lot of factors.
It could be they just missed some of those factors when they tweaked the encoding algorithm.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482632</id>
	<title>Re:Yes</title>
	<author>AK Marc</author>
	<datestamp>1261062600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yeah, but can any of them show a movie with mild action and lightning and not have it look like crap?  Watch the last action scene from Patriot Games on any HD network and see if you don't notice the massive pixelation with every lightning strike.</htmltext>
<tokenext>Yeah , but can any of them show a movie with mild action and lightning and not have it look like crap ?
Watch the last action scene from Patriot Games on any HD network and see if you do n't notice the massive pixelation with every lightning strike .</tokentext>
<sentencetext>Yeah, but can any of them show a movie with mild action and lightning and not have it look like crap?
Watch the last action scene from Patriot Games on any HD network and see if you don't notice the massive pixelation with every lightning strike.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477328</id>
	<title>So what you're saying is..</title>
	<author>msimm</author>
	<datestamp>1261081260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>So what you're saying is although they tested it, they didn't test it.<nobr> <wbr></nobr>;-)</htmltext>
<tokenext>So what you 're saying is although they tested it , they did n't test it .
; - )</tokentext>
<sentencetext>So what you're saying is although they tested it, they didn't test it.
;-)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482758</id>
	<title>Re:Crap HD Quality</title>
	<author>Anonymous</author>
	<datestamp>1261063500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The problem with live digital video feeds is that they have to be encoded and pumped down the tubes on the fly. Digital video doesn't really lend itself to this practically, it much prefers to be encoded in advance with all bitrate and buffering parameters constant and known in advance. The actual amount of available bandwidth in your satellite or cable feed depends entirely on the bitrate of all the other streams in the pipe at any given moment, something that's impossible to predict. Usually there's a delay of a few seconds on so-called live video, and the longer it is the more "future" source material the encoder can look at to decide what to do now with the bitrate it's got at the moment and how much of the decoder's buffer to hold on to for later frames, but that bit reservoir doesn't last long when the camera starts panning and tracking quickly or there's a lot of action on screen.</p><p>There's absolutely *nothing* anyone can do about these problems using today's technical solutions. Option 1 is putting a longer delay on your live feed, which I'm sure is probably legally mandated against by the sports betting industry, among others. Option 2 is to reduce the number of channels and get more stable data available for live streams, but it depends on support of the hardware your customers already have, plus providing bandwidth costs money and you can't have it sitting around doing nothing. Option 3 is to increase the size of the decoder buffer which involves upgrading pretty much every piece of hardware in the distribution network and installed at the customers home, and it won't make that much difference unless it's a substantial (read: extremely expensive) upgrade. Option 4 is to beef up the encoder to increase quality, but live streams have to be encoded in real-time and the amount of processing power it takes to increase quality scales in an exponential fashion, so it's another very expensive option or one that will slowly evolve over time. Option 5 is to increase encoding complexity to increase quality without upping the bit-rate (see downsides of options 3 &amp; 4 above, replacing "encod[er/ed]" in 4 with "decod[er/ed]").</p><p>Short version: Get used the blocking during live fast action scenes, it's here to stay for quite a while.</p></htmltext>
<tokenext>The problem with live digital video feeds is that they have to be encoded and pumped down the tubes on the fly .
Digital video does n't really lend itself to this practically , it much prefers to be encoded in advance with all bitrate and buffering parameters constant and known in advance .
The actual amount of available bandwidth in your satellite or cable feed depends entirely on the bitrate of all the other streams in the pipe at any given moment , something that 's impossible to predict .
Usually there 's a delay of a few seconds on so-called live video , and the longer it is the more " future " source material the encoder can look at to decide what to do now with the bitrate it 's got at the moment and how much of the decoder 's buffer to hold on to for later frames , but that bit reservoir does n't last long when the camera starts panning and tracking quickly or there 's a lot of action on screen.There 's absolutely * nothing * anyone can do about these problems using today 's technical solutions .
Option 1 is putting a longer delay on your live feed , which I 'm sure is probably legally mandated against by the sports betting industry , among others .
Option 2 is to reduce the number of channels and get more stable data available for live streams , but it depends on support of the hardware your customers already have , plus providing bandwidth costs money and you ca n't have it sitting around doing nothing .
Option 3 is to increase the size of the decoder buffer which involves upgrading pretty much every piece of hardware in the distribution network and installed at the customers home , and it wo n't make that much difference unless it 's a substantial ( read : extremely expensive ) upgrade .
Option 4 is to beef up the encoder to increase quality , but live streams have to be encoded in real-time and the amount of processing power it takes to increase quality scales in an exponential fashion , so it 's another very expensive option or one that will slowly evolve over time .
Option 5 is to increase encoding complexity to increase quality without upping the bit-rate ( see downsides of options 3 &amp; 4 above , replacing " encod [ er/ed ] " in 4 with " decod [ er/ed ] " ) .Short version : Get used the blocking during live fast action scenes , it 's here to stay for quite a while .</tokentext>
<sentencetext>The problem with live digital video feeds is that they have to be encoded and pumped down the tubes on the fly.
Digital video doesn't really lend itself to this practically, it much prefers to be encoded in advance with all bitrate and buffering parameters constant and known in advance.
The actual amount of available bandwidth in your satellite or cable feed depends entirely on the bitrate of all the other streams in the pipe at any given moment, something that's impossible to predict.
Usually there's a delay of a few seconds on so-called live video, and the longer it is the more "future" source material the encoder can look at to decide what to do now with the bitrate it's got at the moment and how much of the decoder's buffer to hold on to for later frames, but that bit reservoir doesn't last long when the camera starts panning and tracking quickly or there's a lot of action on screen.There's absolutely *nothing* anyone can do about these problems using today's technical solutions.
Option 1 is putting a longer delay on your live feed, which I'm sure is probably legally mandated against by the sports betting industry, among others.
Option 2 is to reduce the number of channels and get more stable data available for live streams, but it depends on support of the hardware your customers already have, plus providing bandwidth costs money and you can't have it sitting around doing nothing.
Option 3 is to increase the size of the decoder buffer which involves upgrading pretty much every piece of hardware in the distribution network and installed at the customers home, and it won't make that much difference unless it's a substantial (read: extremely expensive) upgrade.
Option 4 is to beef up the encoder to increase quality, but live streams have to be encoded in real-time and the amount of processing power it takes to increase quality scales in an exponential fashion, so it's another very expensive option or one that will slowly evolve over time.
Option 5 is to increase encoding complexity to increase quality without upping the bit-rate (see downsides of options 3 &amp; 4 above, replacing "encod[er/ed]" in 4 with "decod[er/ed]").Short version: Get used the blocking during live fast action scenes, it's here to stay for quite a while.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481218</id>
	<title>Watch what you're saying....</title>
	<author>rew</author>
	<datestamp>1261053780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>...' I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?"</i><br>That's not a problem. Apparently you don't understand coding. But then don't pretend you do, and laugh without understanding the issues.</p><p>Suppose I have an interesting high-res picture, but half of it is sky. Now if I code this in two ways. First I do a high quality jpeg. Very little bits go to the blue background, and lots can be allocated for the interesting parts. Also I save the original as a BMP (uncompressed). The BMP is MUCH larger than the jpeg. Now to reduce the number of bits in the BMP I scale it down by 2x on both sides. So now I might have a 6 megapixel JPEG, and a scaled down 1.5Mpixel BMP. The BMP comes to 4.5 Mbyte. But the 6Mpixel JPEG will look better and it has more details. Still it consumes less bytes (say only 1 or two Mbyte).</p><p>This is just an example where the lower bitrate can outperform a higher bitrate. Now I'm pretty sure that the old higher-bitrate encoding wasn't as stupid as being uncompressed as in my example. Still, it can very well be that the old codec was sufficiently outdated that it can be outperformed by a more modern codec at a lower bitrate.</p><p>However if you switch codecs people will be  used to the old codec and its artefacts. So they will notice the change. Then you'll get complaints valid or not.</p><p>Anyway, even IF a modern codec can outperform an older one at a lower bitrate, it remains to be seen if this modern codec at 9.7 Mbps can outperform the older one at 16Mbps.</p></htmltext>
<tokenext>... ' I got a good laugh off of this , but is it really possible to get better quality from a lower bitrate ?
" That 's not a problem .
Apparently you do n't understand coding .
But then do n't pretend you do , and laugh without understanding the issues.Suppose I have an interesting high-res picture , but half of it is sky .
Now if I code this in two ways .
First I do a high quality jpeg .
Very little bits go to the blue background , and lots can be allocated for the interesting parts .
Also I save the original as a BMP ( uncompressed ) .
The BMP is MUCH larger than the jpeg .
Now to reduce the number of bits in the BMP I scale it down by 2x on both sides .
So now I might have a 6 megapixel JPEG , and a scaled down 1.5Mpixel BMP .
The BMP comes to 4.5 Mbyte .
But the 6Mpixel JPEG will look better and it has more details .
Still it consumes less bytes ( say only 1 or two Mbyte ) .This is just an example where the lower bitrate can outperform a higher bitrate .
Now I 'm pretty sure that the old higher-bitrate encoding was n't as stupid as being uncompressed as in my example .
Still , it can very well be that the old codec was sufficiently outdated that it can be outperformed by a more modern codec at a lower bitrate.However if you switch codecs people will be used to the old codec and its artefacts .
So they will notice the change .
Then you 'll get complaints valid or not.Anyway , even IF a modern codec can outperform an older one at a lower bitrate , it remains to be seen if this modern codec at 9.7 Mbps can outperform the older one at 16Mbps .</tokentext>
<sentencetext>...' I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?
"That's not a problem.
Apparently you don't understand coding.
But then don't pretend you do, and laugh without understanding the issues.Suppose I have an interesting high-res picture, but half of it is sky.
Now if I code this in two ways.
First I do a high quality jpeg.
Very little bits go to the blue background, and lots can be allocated for the interesting parts.
Also I save the original as a BMP (uncompressed).
The BMP is MUCH larger than the jpeg.
Now to reduce the number of bits in the BMP I scale it down by 2x on both sides.
So now I might have a 6 megapixel JPEG, and a scaled down 1.5Mpixel BMP.
The BMP comes to 4.5 Mbyte.
But the 6Mpixel JPEG will look better and it has more details.
Still it consumes less bytes (say only 1 or two Mbyte).This is just an example where the lower bitrate can outperform a higher bitrate.
Now I'm pretty sure that the old higher-bitrate encoding wasn't as stupid as being uncompressed as in my example.
Still, it can very well be that the old codec was sufficiently outdated that it can be outperformed by a more modern codec at a lower bitrate.However if you switch codecs people will be  used to the old codec and its artefacts.
So they will notice the change.
Then you'll get complaints valid or not.Anyway, even IF a modern codec can outperform an older one at a lower bitrate, it remains to be seen if this modern codec at 9.7 Mbps can outperform the older one at 16Mbps.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478886</id>
	<title>Re:Crap HD Quality</title>
	<author>scribblej</author>
	<datestamp>1261043700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I couldn't agree more, which is why I only read books that have no page numbers or chapter breaks.</p></htmltext>
<tokenext>I could n't agree more , which is why I only read books that have no page numbers or chapter breaks .</tokentext>
<sentencetext>I couldn't agree more, which is why I only read books that have no page numbers or chapter breaks.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478616</id>
	<title>Re:A better model beats higher bitrate every time</title>
	<author>Anonymous</author>
	<datestamp>1261042740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Should really mention things like variable block sizes and arithmetic coding schemes that also yield appreciable increases in compression without compromising quality.</p></htmltext>
<tokenext>Should really mention things like variable block sizes and arithmetic coding schemes that also yield appreciable increases in compression without compromising quality .</tokentext>
<sentencetext>Should really mention things like variable block sizes and arithmetic coding schemes that also yield appreciable increases in compression without compromising quality.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478488</id>
	<title>Re:</title>
	<author>clint999</author>
	<datestamp>1261042200000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><blockquote><div><p>Mostly because it's the difference between singular and plural. While I might shorten Pointy-Haired Boss to PHB, I would also shorten Pointy-Haired Bosses to PHBs, and there is a fundamental difference between one PHB and many PHBs</p></div> </blockquote></div>
	</htmltext>
<tokenext>Mostly because it 's the difference between singular and plural .
While I might shorten Pointy-Haired Boss to PHB , I would also shorten Pointy-Haired Bosses to PHBs , and there is a fundamental difference between one PHB and many PHBs</tokentext>
<sentencetext>Mostly because it's the difference between singular and plural.
While I might shorten Pointy-Haired Boss to PHB, I would also shorten Pointy-Haired Bosses to PHBs, and there is a fundamental difference between one PHB and many PHBs 
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477842</id>
	<title>Re:Summary rounding error</title>
	<author>Idiomatick</author>
	<datestamp>1261083060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>All true but if they said almost 100\% it would be completely invalid naturally whilst still valid by your reckoning.</htmltext>
<tokenext>All true but if they said almost 100 \ % it would be completely invalid naturally whilst still valid by your reckoning .</tokentext>
<sentencetext>All true but if they said almost 100\% it would be completely invalid naturally whilst still valid by your reckoning.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1261077120000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>Yes, if more time and passes are spent encoding the video, lower bitrate CAN result in a higher quality video. However, this does not appear to be the case in this instance.</htmltext>
<tokenext>Yes , if more time and passes are spent encoding the video , lower bitrate CAN result in a higher quality video .
However , this does not appear to be the case in this instance .</tokentext>
<sentencetext>Yes, if more time and passes are spent encoding the video, lower bitrate CAN result in a higher quality video.
However, this does not appear to be the case in this instance.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476250</id>
	<title>of course it's POSSIBLE...</title>
	<author>jamescford</author>
	<datestamp>1261077480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Compression is just the discarding of irrelevant or less relevant information. With images or video, that means keeping the perceptually meaningful content and discarding the rest. An improvement might come about if the encoder was removing irrelevant variations (noise), or smoothing out unnecessary details away from perceptually salient objects (making them easier to see).</p><p>It's pretty hard to make an image encoder that maintains the important perceptual qualities of every possible image, so IF their encoder is good, maybe they just didn't test it on the whole range of stuff they eventually used it on.</p></htmltext>
<tokenext>Compression is just the discarding of irrelevant or less relevant information .
With images or video , that means keeping the perceptually meaningful content and discarding the rest .
An improvement might come about if the encoder was removing irrelevant variations ( noise ) , or smoothing out unnecessary details away from perceptually salient objects ( making them easier to see ) .It 's pretty hard to make an image encoder that maintains the important perceptual qualities of every possible image , so IF their encoder is good , maybe they just did n't test it on the whole range of stuff they eventually used it on .</tokentext>
<sentencetext>Compression is just the discarding of irrelevant or less relevant information.
With images or video, that means keeping the perceptually meaningful content and discarding the rest.
An improvement might come about if the encoder was removing irrelevant variations (noise), or smoothing out unnecessary details away from perceptually salient objects (making them easier to see).It's pretty hard to make an image encoder that maintains the important perceptual qualities of every possible image, so IF their encoder is good, maybe they just didn't test it on the whole range of stuff they eventually used it on.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</id>
	<title>Crap HD Quality</title>
	<author>Anonymous</author>
	<datestamp>1261077540000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Try watching a football game here in the US and you will see what crap quality can be. The turf turns into squares of blur when the camera moves, then returns to blades of grass when the picture is stationary. As soon as you spot it you will hate it. If you don't see it then OK for you.</p><p>I used to have a friend who could spot the two little circles in the top right of a movie in the theater telling the projectionist to change the reel. Once he saw them the movies were never the same again.</p></htmltext>
<tokenext>Try watching a football game here in the US and you will see what crap quality can be .
The turf turns into squares of blur when the camera moves , then returns to blades of grass when the picture is stationary .
As soon as you spot it you will hate it .
If you do n't see it then OK for you.I used to have a friend who could spot the two little circles in the top right of a movie in the theater telling the projectionist to change the reel .
Once he saw them the movies were never the same again .</tokentext>
<sentencetext>Try watching a football game here in the US and you will see what crap quality can be.
The turf turns into squares of blur when the camera moves, then returns to blades of grass when the picture is stationary.
As soon as you spot it you will hate it.
If you don't see it then OK for you.I used to have a friend who could spot the two little circles in the top right of a movie in the theater telling the projectionist to change the reel.
Once he saw them the movies were never the same again.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30485386</id>
	<title>Re:Summary rounding error</title>
	<author>Wildclaw</author>
	<datestamp>1261139700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Yes, its almost 50\% -- if you are, e.g., relating it to the nearest 25\%. (Rounding it to the nearest 25\% it would be just plain 50\%, not "almost 50\%".)</p></div><p>Bad choice of numbers. Using the numbers in the article, it is only 57.5\% on the way between 25 and 50. Calling that almost is a redefinition of the word almost. Of course, if you instead use the interval 0 to 50, you can bring that up to 79\% which could be called almost. But then you have to question the sanity of anyone using a percentage scale consisting of only three values (0,50,100).</p><p>But maybe we are just working our way towards the newspeak percentage scale with only two values.</p></div>
	</htmltext>
<tokenext>Yes , its almost 50 \ % -- if you are , e.g. , relating it to the nearest 25 \ % .
( Rounding it to the nearest 25 \ % it would be just plain 50 \ % , not " almost 50 \ % " .
) Bad choice of numbers .
Using the numbers in the article , it is only 57.5 \ % on the way between 25 and 50 .
Calling that almost is a redefinition of the word almost .
Of course , if you instead use the interval 0 to 50 , you can bring that up to 79 \ % which could be called almost .
But then you have to question the sanity of anyone using a percentage scale consisting of only three values ( 0,50,100 ) .But maybe we are just working our way towards the newspeak percentage scale with only two values .</tokentext>
<sentencetext>Yes, its almost 50\% -- if you are, e.g., relating it to the nearest 25\%.
(Rounding it to the nearest 25\% it would be just plain 50\%, not "almost 50\%".
)Bad choice of numbers.
Using the numbers in the article, it is only 57.5\% on the way between 25 and 50.
Calling that almost is a redefinition of the word almost.
Of course, if you instead use the interval 0 to 50, you can bring that up to 79\% which could be called almost.
But then you have to question the sanity of anyone using a percentage scale consisting of only three values (0,50,100).But maybe we are just working our way towards the newspeak percentage scale with only two values.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481146</id>
	<title>Re:Crap HD Quality</title>
	<author>Anonymous</author>
	<datestamp>1261053300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Huh, I thought everyone could see the reel switch circles.  (They are up there for quite a while, probably a tenth of a second.)  They've never really bothered me.</htmltext>
<tokenext>Huh , I thought everyone could see the reel switch circles .
( They are up there for quite a while , probably a tenth of a second .
) They 've never really bothered me .</tokentext>
<sentencetext>Huh, I thought everyone could see the reel switch circles.
(They are up there for quite a while, probably a tenth of a second.
)  They've never really bothered me.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479154</id>
	<title>Re:Crap HD Quality</title>
	<author>dickens</author>
	<datestamp>1261044600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've never seen a film in which I could not see every one of the reel-change signals.  Is that weird?  I don't have the best vision, either.</p></htmltext>
<tokenext>I 've never seen a film in which I could not see every one of the reel-change signals .
Is that weird ?
I do n't have the best vision , either .</tokentext>
<sentencetext>I've never seen a film in which I could not see every one of the reel-change signals.
Is that weird?
I don't have the best vision, either.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476264</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1261077480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Umm, H.264 doesn't compress anywhere near the rate of MPEG.  That would be why H.264 is much better quality (not to mention the its amazing frame flow, as I call it.)<br>But you are forgetting the multiple past slashdot article posts on how people prefer the sound of an MP3 to CDA.  That situation is a WTF moment, but at least it isn't true with video (yet).</p></htmltext>
<tokenext>Umm , H.264 does n't compress anywhere near the rate of MPEG .
That would be why H.264 is much better quality ( not to mention the its amazing frame flow , as I call it .
) But you are forgetting the multiple past slashdot article posts on how people prefer the sound of an MP3 to CDA .
That situation is a WTF moment , but at least it is n't true with video ( yet ) .</tokentext>
<sentencetext>Umm, H.264 doesn't compress anywhere near the rate of MPEG.
That would be why H.264 is much better quality (not to mention the its amazing frame flow, as I call it.
)But you are forgetting the multiple past slashdot article posts on how people prefer the sound of an MP3 to CDA.
That situation is a WTF moment, but at least it isn't true with video (yet).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1261077900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>You can also get better compression by specifying a more sophisticated compression method within the same codec, for example, since many codecs support various levels of compression.</p><p>Generally, "better" compression (fitting a higher resolution and/or framerate into a smaller size) requires a lot more power to encode and often some more power to decode.  You can use less bitrate to get a quality signal there, but you need "smarter" coders and decoders at the respective ends of the transmission.  So the BBC may have upgraded their compression engine to something that can do "better" compression, thereby fitting the same resolution and framerate into a 40\% smaller stream.  But their customers' television sets might not have the horsepower to decode it at full quality.</p><p>That could easily explain why the BBC's testing went so well but their consumers (with varying brands of TV sets probably mostly tested for British use with the old compression) can't keep up and render an inferior picture.</p><p>It's also possible that, by compressing the video stream into a denser compression method, signal loss is having a greater effect than it did with the old compression method.  The viewers may be seeing artifacts that are the decoder's attempts to fill in the blanks.  The old compression method might have allowed a certain amount of redundancy or error correction that the new one lacks, and the loss of part of the signal has a more visible effect on the new one.</p></htmltext>
<tokenext>You can also get better compression by specifying a more sophisticated compression method within the same codec , for example , since many codecs support various levels of compression.Generally , " better " compression ( fitting a higher resolution and/or framerate into a smaller size ) requires a lot more power to encode and often some more power to decode .
You can use less bitrate to get a quality signal there , but you need " smarter " coders and decoders at the respective ends of the transmission .
So the BBC may have upgraded their compression engine to something that can do " better " compression , thereby fitting the same resolution and framerate into a 40 \ % smaller stream .
But their customers ' television sets might not have the horsepower to decode it at full quality.That could easily explain why the BBC 's testing went so well but their consumers ( with varying brands of TV sets probably mostly tested for British use with the old compression ) ca n't keep up and render an inferior picture.It 's also possible that , by compressing the video stream into a denser compression method , signal loss is having a greater effect than it did with the old compression method .
The viewers may be seeing artifacts that are the decoder 's attempts to fill in the blanks .
The old compression method might have allowed a certain amount of redundancy or error correction that the new one lacks , and the loss of part of the signal has a more visible effect on the new one .</tokentext>
<sentencetext>You can also get better compression by specifying a more sophisticated compression method within the same codec, for example, since many codecs support various levels of compression.Generally, "better" compression (fitting a higher resolution and/or framerate into a smaller size) requires a lot more power to encode and often some more power to decode.
You can use less bitrate to get a quality signal there, but you need "smarter" coders and decoders at the respective ends of the transmission.
So the BBC may have upgraded their compression engine to something that can do "better" compression, thereby fitting the same resolution and framerate into a 40\% smaller stream.
But their customers' television sets might not have the horsepower to decode it at full quality.That could easily explain why the BBC's testing went so well but their consumers (with varying brands of TV sets probably mostly tested for British use with the old compression) can't keep up and render an inferior picture.It's also possible that, by compressing the video stream into a denser compression method, signal loss is having a greater effect than it did with the old compression method.
The viewers may be seeing artifacts that are the decoder's attempts to fill in the blanks.
The old compression method might have allowed a certain amount of redundancy or error correction that the new one lacks, and the loss of part of the signal has a more visible effect on the new one.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476200</id>
	<title>Yes, you can</title>
	<author>Anonymous</author>
	<datestamp>1261077240000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p>You can have a lossless 48khz compressed audio will have a much lower bitrate than PCM audio, and more fidelity.</p><p>Older mp3 compressoion algorithms sounded worse at 256kbit than more modern ones do at 128k or lower.</p><p>Look at the size/quality of MPEG2 vs DivX, h264, etc.</p><p>The submitter is, like most of slashdot, technically clueless.</p></htmltext>
<tokenext>You can have a lossless 48khz compressed audio will have a much lower bitrate than PCM audio , and more fidelity.Older mp3 compressoion algorithms sounded worse at 256kbit than more modern ones do at 128k or lower.Look at the size/quality of MPEG2 vs DivX , h264 , etc.The submitter is , like most of slashdot , technically clueless .</tokentext>
<sentencetext>You can have a lossless 48khz compressed audio will have a much lower bitrate than PCM audio, and more fidelity.Older mp3 compressoion algorithms sounded worse at 256kbit than more modern ones do at 128k or lower.Look at the size/quality of MPEG2 vs DivX, h264, etc.The submitter is, like most of slashdot, technically clueless.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476196</id>
	<title>Yes, of course</title>
	<author>TheRaven64</author>
	<datestamp>1261077240000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext>Any lossy compression works by throwing away bits of the picture that the viewer might not notice.  You can lower the bitrate with better psychovisual and psychoacoustic models.  You're still throwing away more information, but you're doing it in a way that the user is less likely to notice.  This takes more CPU time on the compressor, a more optimised encoder, or a better algorithm.</htmltext>
<tokenext>Any lossy compression works by throwing away bits of the picture that the viewer might not notice .
You can lower the bitrate with better psychovisual and psychoacoustic models .
You 're still throwing away more information , but you 're doing it in a way that the user is less likely to notice .
This takes more CPU time on the compressor , a more optimised encoder , or a better algorithm .</tokentext>
<sentencetext>Any lossy compression works by throwing away bits of the picture that the viewer might not notice.
You can lower the bitrate with better psychovisual and psychoacoustic models.
You're still throwing away more information, but you're doing it in a way that the user is less likely to notice.
This takes more CPU time on the compressor, a more optimised encoder, or a better algorithm.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476430</id>
	<title>Test video</title>
	<author>bugs2squash</author>
	<datestamp>1261078080000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext>was the featureless black-screen video to 4'33" from John Cage. Results were far better at the lower bitrate. The absolute darkness was less blurry.</htmltext>
<tokenext>was the featureless black-screen video to 4'33 " from John Cage .
Results were far better at the lower bitrate .
The absolute darkness was less blurry .</tokentext>
<sentencetext>was the featureless black-screen video to 4'33" from John Cage.
Results were far better at the lower bitrate.
The absolute darkness was less blurry.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261078620000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Yes, it IS possible to get higher picture quality out of a lower bitrate, but not with all else equal. For example, you can get higher quality with CPU-intensive settings using H.264 5.1 Profile than you can with H.264 4.1 (what Blu-Ray's/HD DVDs use), at the same bitrate. You're giving up CPU cycles in decoding for lower video size. This is why x264 can produce near-transparent encodes of Blu-Ray movies at about half the size. x264 uses much more demanding settings.</p><p>x264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.</p></htmltext>
<tokenext>Yes , it IS possible to get higher picture quality out of a lower bitrate , but not with all else equal .
For example , you can get higher quality with CPU-intensive settings using H.264 5.1 Profile than you can with H.264 4.1 ( what Blu-Ray 's/HD DVDs use ) , at the same bitrate .
You 're giving up CPU cycles in decoding for lower video size .
This is why x264 can produce near-transparent encodes of Blu-Ray movies at about half the size .
x264 uses much more demanding settings.x264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray .</tokentext>
<sentencetext>Yes, it IS possible to get higher picture quality out of a lower bitrate, but not with all else equal.
For example, you can get higher quality with CPU-intensive settings using H.264 5.1 Profile than you can with H.264 4.1 (what Blu-Ray's/HD DVDs use), at the same bitrate.
You're giving up CPU cycles in decoding for lower video size.
This is why x264 can produce near-transparent encodes of Blu-Ray movies at about half the size.
x264 uses much more demanding settings.x264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476408</id>
	<title>Re:Yes, of course</title>
	<author>Anonymous</author>
	<datestamp>1261078020000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>LAME was a pretty good example of this for MP3 - Eventually it was able to achieve (somewhat) better quality at (somewhat) lower bitrates than the reference encoders.</p><p>Vorbis, similarly, had the AoTUV tuning - This provided significant rate/distortion tradeoff improvements compared to a "vanilla" encoder, without changing the decoder.</p><p>However, 40\% reduction in bitrate with an increase in quality is very difficult unless the original encoder was CRAP.  (Which is actually a definite possibility for a realtime hardware encoder.)  Also, it's far more likely to have such improvements with H.264 or MPEG-4 ASP, not nearly as likely with MPEG-2, which had a far less flexible encoding scheme.</p></htmltext>
<tokenext>LAME was a pretty good example of this for MP3 - Eventually it was able to achieve ( somewhat ) better quality at ( somewhat ) lower bitrates than the reference encoders.Vorbis , similarly , had the AoTUV tuning - This provided significant rate/distortion tradeoff improvements compared to a " vanilla " encoder , without changing the decoder.However , 40 \ % reduction in bitrate with an increase in quality is very difficult unless the original encoder was CRAP .
( Which is actually a definite possibility for a realtime hardware encoder .
) Also , it 's far more likely to have such improvements with H.264 or MPEG-4 ASP , not nearly as likely with MPEG-2 , which had a far less flexible encoding scheme .</tokentext>
<sentencetext>LAME was a pretty good example of this for MP3 - Eventually it was able to achieve (somewhat) better quality at (somewhat) lower bitrates than the reference encoders.Vorbis, similarly, had the AoTUV tuning - This provided significant rate/distortion tradeoff improvements compared to a "vanilla" encoder, without changing the decoder.However, 40\% reduction in bitrate with an increase in quality is very difficult unless the original encoder was CRAP.
(Which is actually a definite possibility for a realtime hardware encoder.
)  Also, it's far more likely to have such improvements with H.264 or MPEG-4 ASP, not nearly as likely with MPEG-2, which had a far less flexible encoding scheme.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476196</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477170</id>
	<title>Re:Crap HD Quality</title>
	<author>Anonymous</author>
	<datestamp>1261080660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>At least you have OTA HDTV. In Finland, the government, in all its wisdom, decided that the digital transition will not include any improvements in resolution or frame rate (say, by including 24 Hz used in each and every movie). So we're stuck at 720x576 50Hz Interlaced.</p></htmltext>
<tokenext>At least you have OTA HDTV .
In Finland , the government , in all its wisdom , decided that the digital transition will not include any improvements in resolution or frame rate ( say , by including 24 Hz used in each and every movie ) .
So we 're stuck at 720x576 50Hz Interlaced .</tokentext>
<sentencetext>At least you have OTA HDTV.
In Finland, the government, in all its wisdom, decided that the digital transition will not include any improvements in resolution or frame rate (say, by including 24 Hz used in each and every movie).
So we're stuck at 720x576 50Hz Interlaced.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477088</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261080360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I would mod this up but it is already 5...</htmltext>
<tokenext>I would mod this up but it is already 5.. .</tokentext>
<sentencetext>I would mod this up but it is already 5...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476502</id>
	<title>Quite a bit left out</title>
	<author>sunking2</author>
	<datestamp>1261078320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The article talks about bitrate, which implies not a change in codec, so it remains mpeg-2. I'm assuming the BBC is available OTA, so unless they want everyone with a HD ready TV to have to get a new receiver box they can't just change to x264, etc.

So in this context, the answer is no, using the same codec at a reduced bitrate can't produce better than the source. However, that assumes you are comparing to the original source. Take for example a standard DVD player which has a mpeg2 uncompressed file at 480i. The resulting image on a very large 60+" HD TV may appear blocky in some situations. A good DVD player will be able to interpolate and massage things around so that the resulting 1080i image on your screen indeed does look better on your screen. Although the image itself may be quite a bit different than the original pure source. So you have a perceived better frame image, although it may be quite a bit changed from the source.</htmltext>
<tokenext>The article talks about bitrate , which implies not a change in codec , so it remains mpeg-2 .
I 'm assuming the BBC is available OTA , so unless they want everyone with a HD ready TV to have to get a new receiver box they ca n't just change to x264 , etc .
So in this context , the answer is no , using the same codec at a reduced bitrate ca n't produce better than the source .
However , that assumes you are comparing to the original source .
Take for example a standard DVD player which has a mpeg2 uncompressed file at 480i .
The resulting image on a very large 60 + " HD TV may appear blocky in some situations .
A good DVD player will be able to interpolate and massage things around so that the resulting 1080i image on your screen indeed does look better on your screen .
Although the image itself may be quite a bit different than the original pure source .
So you have a perceived better frame image , although it may be quite a bit changed from the source .</tokentext>
<sentencetext>The article talks about bitrate, which implies not a change in codec, so it remains mpeg-2.
I'm assuming the BBC is available OTA, so unless they want everyone with a HD ready TV to have to get a new receiver box they can't just change to x264, etc.
So in this context, the answer is no, using the same codec at a reduced bitrate can't produce better than the source.
However, that assumes you are comparing to the original source.
Take for example a standard DVD player which has a mpeg2 uncompressed file at 480i.
The resulting image on a very large 60+" HD TV may appear blocky in some situations.
A good DVD player will be able to interpolate and massage things around so that the resulting 1080i image on your screen indeed does look better on your screen.
Although the image itself may be quite a bit different than the original pure source.
So you have a perceived better frame image, although it may be quite a bit changed from the source.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477110</id>
	<title>Re:Their new algorithm?</title>
	<author>Anonymous</author>
	<datestamp>1261080480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>By subtracting 0101100101000000</p></htmltext>
<tokenext>By subtracting 0101100101000000</tokentext>
<sentencetext>By subtracting 0101100101000000</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476222</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476348</id>
	<title>BBC evil Jedi</title>
	<author>jdgeorge</author>
	<datestamp>1261077780000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><p>BBC accountant: We provide the $ame or better picture quality with half the bitrate! Just think of the $aving$!</p><p>BBC IT decision maker: I $ee what you're $aying.... The$e picture$ look $uper!</p><p>Public: This looks like crap.</p><p>BBC rep: (waves hand) The$e aren't the compre$$ion artifact$ you're looking for. We can go about our bu$ine$$. There are no complaint$.</p></htmltext>
<tokenext>BBC accountant : We provide the $ ame or better picture quality with half the bitrate !
Just think of the $ aving $ ! BBC IT decision maker : I $ ee what you 're $ aying.... The $ e picture $ look $ uper ! Public : This looks like crap.BBC rep : ( waves hand ) The $ e are n't the compre $ $ ion artifact $ you 're looking for .
We can go about our bu $ ine $ $ .
There are no complaint $ .</tokentext>
<sentencetext>BBC accountant: We provide the $ame or better picture quality with half the bitrate!
Just think of the $aving$!BBC IT decision maker: I $ee what you're $aying.... The$e picture$ look $uper!Public: This looks like crap.BBC rep: (waves hand) The$e aren't the compre$$ion artifact$ you're looking for.
We can go about our bu$ine$$.
There are no complaint$.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479234</id>
	<title>Re:Crap HD Quality</title>
	<author>harl</author>
	<datestamp>1261044900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Speaking about college broadcast.  I don't watch the NFL.</p><p>It seems to vary by channel.  CBS has a noticeably lower quality HD feed than ABC.  I don't remember NBC standing out as particularly better or worse but they only show one team so I hardly ever watch it.</p><p>This is all for over the air HD so it may vary by local station.  If you haven't checked out over the air HD do so.  It's pretty damn good and all you need is a $20 pos loop antenna.</p></htmltext>
<tokenext>Speaking about college broadcast .
I do n't watch the NFL.It seems to vary by channel .
CBS has a noticeably lower quality HD feed than ABC .
I do n't remember NBC standing out as particularly better or worse but they only show one team so I hardly ever watch it.This is all for over the air HD so it may vary by local station .
If you have n't checked out over the air HD do so .
It 's pretty damn good and all you need is a $ 20 pos loop antenna .</tokentext>
<sentencetext>Speaking about college broadcast.
I don't watch the NFL.It seems to vary by channel.
CBS has a noticeably lower quality HD feed than ABC.
I don't remember NBC standing out as particularly better or worse but they only show one team so I hardly ever watch it.This is all for over the air HD so it may vary by local station.
If you haven't checked out over the air HD do so.
It's pretty damn good and all you need is a $20 pos loop antenna.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476420</id>
	<title>Obligatory XKCD</title>
	<author>sydneyfong</author>
	<datestamp>1261078020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><a href="http://xkcd.com/598/" title="xkcd.com">http://xkcd.com/598/</a> [xkcd.com]</p></htmltext>
<tokenext>http : //xkcd.com/598/ [ xkcd.com ]</tokentext>
<sentencetext>http://xkcd.com/598/ [xkcd.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477574</id>
	<title>Re:Yes</title>
	<author>Idiomatick</author>
	<datestamp>1261082100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You could also quarter the frame rate<nobr> <wbr></nobr>:D</htmltext>
<tokenext>You could also quarter the frame rate : D</tokentext>
<sentencetext>You could also quarter the frame rate :D</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482222</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1261059600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just a point of clarification on your post.  The h.264 standard is for how to <b>decode</b> an h.264 stream.  There is no standard on how to <b>encode</b> the video.  </p><p>In agreement with parent, having a smarter encoder can make a huge difference, as can having the needed resouces to decode computationally expensive stream.</p></htmltext>
<tokenext>Just a point of clarification on your post .
The h.264 standard is for how to decode an h.264 stream .
There is no standard on how to encode the video .
In agreement with parent , having a smarter encoder can make a huge difference , as can having the needed resouces to decode computationally expensive stream .</tokentext>
<sentencetext>Just a point of clarification on your post.
The h.264 standard is for how to decode an h.264 stream.
There is no standard on how to encode the video.
In agreement with parent, having a smarter encoder can make a huge difference, as can having the needed resouces to decode computationally expensive stream.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480602</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1261050300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>is it really possible to get better quality from a lower bitrate?</p></div><p>Yyyyeeessssss, maaaybe yyyooouuuu caaaan.<br>Yes, you can.</p></div>
	</htmltext>
<tokenext>is it really possible to get better quality from a lower bitrate ? Yyyyeeessssss , maaaybe yyyooouuuu caaaan.Yes , you can .</tokentext>
<sentencetext>is it really possible to get better quality from a lower bitrate?Yyyyeeessssss, maaaybe yyyooouuuu caaaan.Yes, you can.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478764</id>
	<title>Re:Summary rounding error</title>
	<author>Skapare</author>
	<datestamp>1261043280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So someone forgot to turn on the percentage number compression.</p></htmltext>
<tokenext>So someone forgot to turn on the percentage number compression .</tokentext>
<sentencetext>So someone forgot to turn on the percentage number compression.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476672</id>
	<title>Re:Crap HD Quality</title>
	<author>Brett Buck</author>
	<datestamp>1261078920000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>I think you might want to talk to you cable company on that one. I know the effect you are seeing (it's by far the worst on local Public TV since they crammed 7 sub-channels into the same carrier), but network TV coverage of football in my area is pretty pristine for the most part. OTA is even better but cable is still awfully good.</p><p>
&nbsp; &nbsp; &nbsp; Of course, by "talk to your cable company", I mean "do nothing" because talking to the cable company is a complete waste of time.</p><p>
&nbsp; &nbsp; &nbsp; Brett</p></htmltext>
<tokenext>I think you might want to talk to you cable company on that one .
I know the effect you are seeing ( it 's by far the worst on local Public TV since they crammed 7 sub-channels into the same carrier ) , but network TV coverage of football in my area is pretty pristine for the most part .
OTA is even better but cable is still awfully good .
      Of course , by " talk to your cable company " , I mean " do nothing " because talking to the cable company is a complete waste of time .
      Brett</tokentext>
<sentencetext>I think you might want to talk to you cable company on that one.
I know the effect you are seeing (it's by far the worst on local Public TV since they crammed 7 sub-channels into the same carrier), but network TV coverage of football in my area is pretty pristine for the most part.
OTA is even better but cable is still awfully good.
      Of course, by "talk to your cable company", I mean "do nothing" because talking to the cable company is a complete waste of time.
      Brett</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477804</id>
	<title>Re:Focus group...</title>
	<author>dubbreak</author>
	<datestamp>1261082880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p>FTA: ""Even my wife can see a reduction in picture quality and she's got cataracts," wrote one. "</p></div><p>They must have a pretty big screen if she can see that difference from the kitchen.</p></div><p>I hear cold flooring on bare feet and fetal related hormones increase visual acuity.</p></div>
	</htmltext>
<tokenext>FTA : " " Even my wife can see a reduction in picture quality and she 's got cataracts , " wrote one .
" They must have a pretty big screen if she can see that difference from the kitchen.I hear cold flooring on bare feet and fetal related hormones increase visual acuity .</tokentext>
<sentencetext>FTA: ""Even my wife can see a reduction in picture quality and she's got cataracts," wrote one.
"They must have a pretty big screen if she can see that difference from the kitchen.I hear cold flooring on bare feet and fetal related hormones increase visual acuity.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482134</id>
	<title>Re:Crap HD Quality</title>
	<author>meowhous</author>
	<datestamp>1261059060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>It's really not all that crippling, and usually they're ovals.  If you see them at all any more.  Usually they occur near a natural break in the action anyway, and there are usually other clues that just this visual to that in the near future.  Possibly it's more disturbing if for some period you were needed to notice these because you might be there to wake up the projectionist if the reel transition doesn't happen.
<br>

<br>
What I find more disturbing are the dark red dots, frequently in the pattern you'd see on the 5-side of a die, right in the middle of the screen.  Or maybe it's just me that sees them EVERY TIME I go to the cinema.</htmltext>
<tokenext>It 's really not all that crippling , and usually they 're ovals .
If you see them at all any more .
Usually they occur near a natural break in the action anyway , and there are usually other clues that just this visual to that in the near future .
Possibly it 's more disturbing if for some period you were needed to notice these because you might be there to wake up the projectionist if the reel transition does n't happen .
What I find more disturbing are the dark red dots , frequently in the pattern you 'd see on the 5-side of a die , right in the middle of the screen .
Or maybe it 's just me that sees them EVERY TIME I go to the cinema .</tokentext>
<sentencetext>It's really not all that crippling, and usually they're ovals.
If you see them at all any more.
Usually they occur near a natural break in the action anyway, and there are usually other clues that just this visual to that in the near future.
Possibly it's more disturbing if for some period you were needed to notice these because you might be there to wake up the projectionist if the reel transition doesn't happen.
What I find more disturbing are the dark red dots, frequently in the pattern you'd see on the 5-side of a die, right in the middle of the screen.
Or maybe it's just me that sees them EVERY TIME I go to the cinema.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477840</id>
	<title>Re:Yes</title>
	<author>Alarash</author>
	<datestamp>1261083060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You are correct until the last paragraph. H.264, MPEG-4 and MPEG-2 all use MPEG2-TS (Transport Stream) and the effect of data loss are therefore identical because they all use I, P and B frames to store the encoded data.</p><p>Also the only way to measure video quality is <a href="http://en.wikipedia.org/wiki/Mean\_opinion\_score" title="wikipedia.org">MOS</a> [wikipedia.org] (for perceived quality, ie: the quality of the picture) and <a href="http://en.wikipedia.org/wiki/Media\_Delivery\_Index" title="wikipedia.org">MDI</a> [wikipedia.org] (for transport quality, ie: the impact of the transport on the quality - jitter, latency and packet loss are the most important factors). You can have a perfect MDI (no loss of quality due to the transport layer) but shitty MOS because of a poor codec.</p></htmltext>
<tokenext>You are correct until the last paragraph .
H.264 , MPEG-4 and MPEG-2 all use MPEG2-TS ( Transport Stream ) and the effect of data loss are therefore identical because they all use I , P and B frames to store the encoded data.Also the only way to measure video quality is MOS [ wikipedia.org ] ( for perceived quality , ie : the quality of the picture ) and MDI [ wikipedia.org ] ( for transport quality , ie : the impact of the transport on the quality - jitter , latency and packet loss are the most important factors ) .
You can have a perfect MDI ( no loss of quality due to the transport layer ) but shitty MOS because of a poor codec .</tokentext>
<sentencetext>You are correct until the last paragraph.
H.264, MPEG-4 and MPEG-2 all use MPEG2-TS (Transport Stream) and the effect of data loss are therefore identical because they all use I, P and B frames to store the encoded data.Also the only way to measure video quality is MOS [wikipedia.org] (for perceived quality, ie: the quality of the picture) and MDI [wikipedia.org] (for transport quality, ie: the impact of the transport on the quality - jitter, latency and packet loss are the most important factors).
You can have a perfect MDI (no loss of quality due to the transport layer) but shitty MOS because of a poor codec.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30484294</id>
	<title>Re:It depends on the material</title>
	<author>Anonymous</author>
	<datestamp>1261166940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>It's been done: <a href="http://en.wikipedia.org/wiki/World\_Wrestling\_Entertainment" title="wikipedia.org" rel="nofollow">WWE</a> [wikipedia.org]</htmltext>
<tokenext>It 's been done : WWE [ wikipedia.org ]</tokentext>
<sentencetext>It's been done: WWE [wikipedia.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481948</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482580</id>
	<title>x264 doesn't support interlacing properly?</title>
	<author>Anonymous</author>
	<datestamp>1261062060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>But x264 doesn't support interlacing properly (or efficiently)? That's what I was told a while back. Haven't investigated it myself.</p><p>Most SDTV and HDTV content is interlaced, so not supporting proper interlacing makes a codec somewhat redundant...</p></htmltext>
<tokenext>But x264 does n't support interlacing properly ( or efficiently ) ?
That 's what I was told a while back .
Have n't investigated it myself.Most SDTV and HDTV content is interlaced , so not supporting proper interlacing makes a codec somewhat redundant.. .</tokentext>
<sentencetext>But x264 doesn't support interlacing properly (or efficiently)?
That's what I was told a while back.
Haven't investigated it myself.Most SDTV and HDTV content is interlaced, so not supporting proper interlacing makes a codec somewhat redundant...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476224</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478318</id>
	<title>Re:Quite a bit left out</title>
	<author>Anonymous</author>
	<datestamp>1261041480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Sorry, but that's just plain wrong. Just ask Theora guys.</p><p>example: http://web.mit.edu/xiphmont/Public/theora/demo5.html</p></htmltext>
<tokenext>Sorry , but that 's just plain wrong .
Just ask Theora guys.example : http : //web.mit.edu/xiphmont/Public/theora/demo5.html</tokentext>
<sentencetext>Sorry, but that's just plain wrong.
Just ask Theora guys.example: http://web.mit.edu/xiphmont/Public/theora/demo5.html</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476502</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482090</id>
	<title>Re:Crap HD Quality</title>
	<author>geekoid</author>
	<datestamp>1261058820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It also depends on the quality of his viewing device.</p><p>This will happen ion 60Hz TVs' even at 1080p</p></htmltext>
<tokenext>It also depends on the quality of his viewing device.This will happen ion 60Hz TVs ' even at 1080p</tokentext>
<sentencetext>It also depends on the quality of his viewing device.This will happen ion 60Hz TVs' even at 1080p</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476672</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481948</id>
	<title>Re:It depends on the material</title>
	<author>lennier</author>
	<datestamp>1261057920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"If you're watching a soap opera, you only need to see a few frames per week to follow the story. If you are watching a live sports event with a lot of action..."</p><p>Okay, someone needs to make a soap opera about live sports and capture both the hardcore male and female demographics.</p><p>though I suppose that's what reality TV is...</p></htmltext>
<tokenext>" If you 're watching a soap opera , you only need to see a few frames per week to follow the story .
If you are watching a live sports event with a lot of action... " Okay , someone needs to make a soap opera about live sports and capture both the hardcore male and female demographics.though I suppose that 's what reality TV is.. .</tokentext>
<sentencetext>"If you're watching a soap opera, you only need to see a few frames per week to follow the story.
If you are watching a live sports event with a lot of action..."Okay, someone needs to make a soap opera about live sports and capture both the hardcore male and female demographics.though I suppose that's what reality TV is...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476290</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477330</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1261081260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Generally, "better" compression (fitting a higher resolution and/or framerate into a smaller size)</p></div><p>Er... no. Broadcast TV compressors don't work by reducing the resolution or number of frames per second of a given stream (that would be a different video standard, not increased compression).</p><p>"Better" video compression simply manages to retain images that are closer to the original while fitting in the same bitrate (or squeeze images of equivalent quality into a lower bitrate). The frame rate and image resolution (dimensions in pixels) will be the same.</p></div>
	</htmltext>
<tokenext>Generally , " better " compression ( fitting a higher resolution and/or framerate into a smaller size ) Er... no. Broadcast TV compressors do n't work by reducing the resolution or number of frames per second of a given stream ( that would be a different video standard , not increased compression ) .
" Better " video compression simply manages to retain images that are closer to the original while fitting in the same bitrate ( or squeeze images of equivalent quality into a lower bitrate ) .
The frame rate and image resolution ( dimensions in pixels ) will be the same .</tokentext>
<sentencetext>Generally, "better" compression (fitting a higher resolution and/or framerate into a smaller size)Er... no. Broadcast TV compressors don't work by reducing the resolution or number of frames per second of a given stream (that would be a different video standard, not increased compression).
"Better" video compression simply manages to retain images that are closer to the original while fitting in the same bitrate (or squeeze images of equivalent quality into a lower bitrate).
The frame rate and image resolution (dimensions in pixels) will be the same.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476262</id>
	<title>Sure!</title>
	<author>Anonymous</author>
	<datestamp>1261077480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p> is it really possible to get better quality from a lower bitrate?</p></div><p>
It is, if your original encoders sucked...</p></div>
	</htmltext>
<tokenext>is it really possible to get better quality from a lower bitrate ?
It is , if your original encoders sucked.. .</tokentext>
<sentencetext> is it really possible to get better quality from a lower bitrate?
It is, if your original encoders sucked...
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481412</id>
	<title>We're all being sold a pup</title>
	<author>GrahamCox</author>
	<datestamp>1261055100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm fed up with hearing and reading how "digital TV delivers better quality images (and sound)". It does no such thing. It's obvious that the picture quality is poorer than a good analogue signal - some images break up altogether, like sunlight on rippling water. It may help cram more channels into less space, but that's not really an end-user benefit (it doesn't necessarily translate into more choice, here in Australia it just means more repeats).</htmltext>
<tokenext>I 'm fed up with hearing and reading how " digital TV delivers better quality images ( and sound ) " .
It does no such thing .
It 's obvious that the picture quality is poorer than a good analogue signal - some images break up altogether , like sunlight on rippling water .
It may help cram more channels into less space , but that 's not really an end-user benefit ( it does n't necessarily translate into more choice , here in Australia it just means more repeats ) .</tokentext>
<sentencetext>I'm fed up with hearing and reading how "digital TV delivers better quality images (and sound)".
It does no such thing.
It's obvious that the picture quality is poorer than a good analogue signal - some images break up altogether, like sunlight on rippling water.
It may help cram more channels into less space, but that's not really an end-user benefit (it doesn't necessarily translate into more choice, here in Australia it just means more repeats).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480618</id>
	<title>Re:Summary rounding error</title>
	<author>Anonymous</author>
	<datestamp>1261050420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The bitrate of image data can be reduced,  the bitrate of frame headers and markers, cannot.</p></htmltext>
<tokenext>The bitrate of image data can be reduced , the bitrate of frame headers and markers , can not .</tokentext>
<sentencetext>The bitrate of image data can be reduced,  the bitrate of frame headers and markers, cannot.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480786</id>
	<title>We'll just get used to it</title>
	<author>HockeyPuck</author>
	<datestamp>1261051140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>We used to buy music on Records and CDs.</p><p>Now we listen to music on highly compressed mp3s.  Most people have been listening to mp3s for so long they don't remember (or care) the difference of the higher quality of what a good record or CD used to sound like.</p><p>So give the people in the UK a few months and they won't remember what days with higher quality HDTV were like. Especially as we move towards streaming content.  Comcast compresses, Netflix transmits audio in stereo.  I can't wait for HDTV 1080bw (it's 1080p but in Black and White).</p></htmltext>
<tokenext>We used to buy music on Records and CDs.Now we listen to music on highly compressed mp3s .
Most people have been listening to mp3s for so long they do n't remember ( or care ) the difference of the higher quality of what a good record or CD used to sound like.So give the people in the UK a few months and they wo n't remember what days with higher quality HDTV were like .
Especially as we move towards streaming content .
Comcast compresses , Netflix transmits audio in stereo .
I ca n't wait for HDTV 1080bw ( it 's 1080p but in Black and White ) .</tokentext>
<sentencetext>We used to buy music on Records and CDs.Now we listen to music on highly compressed mp3s.
Most people have been listening to mp3s for so long they don't remember (or care) the difference of the higher quality of what a good record or CD used to sound like.So give the people in the UK a few months and they won't remember what days with higher quality HDTV were like.
Especially as we move towards streaming content.
Comcast compresses, Netflix transmits audio in stereo.
I can't wait for HDTV 1080bw (it's 1080p but in Black and White).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479840</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261047060000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext>Maybe she noticed it while delivering a beer or chips to the living room?</htmltext>
<tokenext>Maybe she noticed it while delivering a beer or chips to the living room ?</tokentext>
<sentencetext>Maybe she noticed it while delivering a beer or chips to the living room?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30488252</id>
	<title>Re:Crap HD Quality</title>
	<author>Anonymous</author>
	<datestamp>1261156080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>CBS seems to have the best HD quality for NFL games.     ESPN is probably 2nd.    Fox has decent on-field quality but their studio footage is terrible.  NBC has better studio than Fox but not better for on-field.</p></htmltext>
<tokenext>CBS seems to have the best HD quality for NFL games .
ESPN is probably 2nd .
Fox has decent on-field quality but their studio footage is terrible .
NBC has better studio than Fox but not better for on-field .</tokentext>
<sentencetext>CBS seems to have the best HD quality for NFL games.
ESPN is probably 2nd.
Fox has decent on-field quality but their studio footage is terrible.
NBC has better studio than Fox but not better for on-field.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170</id>
	<title>Yes</title>
	<author>Anonymous</author>
	<datestamp>1261077180000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><blockquote><div><p>I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?</p></div></blockquote><p>
Sure, if you also switch to a better codec, such as using H.264 instead of MPEG-2. However, I don't think that's what's happening in this case.</p></div>
	</htmltext>
<tokenext>I got a good laugh off of this , but is it really possible to get better quality from a lower bitrate ?
Sure , if you also switch to a better codec , such as using H.264 instead of MPEG-2 .
However , I do n't think that 's what 's happening in this case .</tokentext>
<sentencetext>I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?
Sure, if you also switch to a better codec, such as using H.264 instead of MPEG-2.
However, I don't think that's what's happening in this case.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481088</id>
	<title>Re:Focus group...</title>
	<author>clint999</author>
	<datestamp>1261053000000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><i>What a weird post.  Would you find it less offensive if you weren't a C programmer?  It may be a stereotype, but it is there for a reason.  This hits home with my mom who says she can't tell the difference between standard def and high def television.  Does that mean all women can't?  Nope.  But it was an amusing quote...loosen up.  Stop looking for things to be offended about.</i></div>
	</htmltext>
<tokenext>What a weird post .
Would you find it less offensive if you were n't a C programmer ?
It may be a stereotype , but it is there for a reason .
This hits home with my mom who says she ca n't tell the difference between standard def and high def television .
Does that mean all women ca n't ?
Nope. But it was an amusing quote...loosen up .
Stop looking for things to be offended about .</tokentext>
<sentencetext>What a weird post.
Would you find it less offensive if you weren't a C programmer?
It may be a stereotype, but it is there for a reason.
This hits home with my mom who says she can't tell the difference between standard def and high def television.
Does that mean all women can't?
Nope.  But it was an amusing quote...loosen up.
Stop looking for things to be offended about.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476770</id>
	<title>Blank screen</title>
	<author>LeadSongDog</author>
	<datestamp>1261079220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Nothing to see here. Move along.</htmltext>
<tokenext>Nothing to see here .
Move along .</tokentext>
<sentencetext>Nothing to see here.
Move along.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478458</id>
	<title>You can getter better quality from a lower bitrate</title>
	<author>DrXym</author>
	<datestamp>1261042080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Generally speaking the higher the bitrate, the higher the quality, but all encoders are not equal and it's entirely possible that the BBC do get subjectively similar quality from switching to a different vendor. At the same time, there are limits to how low they can go before people start noticing the artifacts. Too many channels, especially paid/commercial channels step way too far over the line and the screen disintegrates into blocky mush when too much is going on. Conversely, pushing the bitrate higher invokes the law of diminishing returns. I realise the BBC are probably starved of bandwidth but at the same time, they need to strike a reasonable balance rather than shoving as many channels in as possible.
<p>
I think if the BBC wants to test if their new arrangement is degrading image quality, they should put up some randomized A/B pictures from both setups and ask users to pick. If they honestly believe the new setup is comparable then the results should be 50:50.</p></htmltext>
<tokenext>Generally speaking the higher the bitrate , the higher the quality , but all encoders are not equal and it 's entirely possible that the BBC do get subjectively similar quality from switching to a different vendor .
At the same time , there are limits to how low they can go before people start noticing the artifacts .
Too many channels , especially paid/commercial channels step way too far over the line and the screen disintegrates into blocky mush when too much is going on .
Conversely , pushing the bitrate higher invokes the law of diminishing returns .
I realise the BBC are probably starved of bandwidth but at the same time , they need to strike a reasonable balance rather than shoving as many channels in as possible .
I think if the BBC wants to test if their new arrangement is degrading image quality , they should put up some randomized A/B pictures from both setups and ask users to pick .
If they honestly believe the new setup is comparable then the results should be 50 : 50 .</tokentext>
<sentencetext>Generally speaking the higher the bitrate, the higher the quality, but all encoders are not equal and it's entirely possible that the BBC do get subjectively similar quality from switching to a different vendor.
At the same time, there are limits to how low they can go before people start noticing the artifacts.
Too many channels, especially paid/commercial channels step way too far over the line and the screen disintegrates into blocky mush when too much is going on.
Conversely, pushing the bitrate higher invokes the law of diminishing returns.
I realise the BBC are probably starved of bandwidth but at the same time, they need to strike a reasonable balance rather than shoving as many channels in as possible.
I think if the BBC wants to test if their new arrangement is degrading image quality, they should put up some randomized A/B pictures from both setups and ask users to pick.
If they honestly believe the new setup is comparable then the results should be 50:50.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476658</id>
	<title>Re:Yes</title>
	<author>Zebra\_X</author>
	<datestamp>1261078860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>H.264 = MPEG-4 Part 10 (http://en.wikipedia.org/wiki/H.264/MPEG-4\_AVC)</p><p>If you mean MPEG-2, H.264 was designed as a replacement for this technology amongst others.</p><p>H.264 and VC-1 are currently the most efficient methods in terms of bandwidth to transmit video.</p></htmltext>
<tokenext>H.264 = MPEG-4 Part 10 ( http : //en.wikipedia.org/wiki/H.264/MPEG-4 \ _AVC ) If you mean MPEG-2 , H.264 was designed as a replacement for this technology amongst others.H.264 and VC-1 are currently the most efficient methods in terms of bandwidth to transmit video .</tokentext>
<sentencetext>H.264 = MPEG-4 Part 10 (http://en.wikipedia.org/wiki/H.264/MPEG-4\_AVC)If you mean MPEG-2, H.264 was designed as a replacement for this technology amongst others.H.264 and VC-1 are currently the most efficient methods in terms of bandwidth to transmit video.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476264</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476294</id>
	<title>Re:Focus group...</title>
	<author>DoofusOfDeath</author>
	<datestamp>1261077540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Focus group of blind retards.</p></div></blockquote><p>"And do you know why?  Because they're Scotts!  Ha ha ha ha hah!"</p><p>Sigh...</p></div>
	</htmltext>
<tokenext>Focus group of blind retards .
" And do you know why ?
Because they 're Scotts !
Ha ha ha ha hah !
" Sigh.. .</tokentext>
<sentencetext>Focus group of blind retards.
"And do you know why?
Because they're Scotts!
Ha ha ha ha hah!
"Sigh...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477436</id>
	<title>Re:A better model beats higher bitrate every time</title>
	<author>Anonymous</author>
	<datestamp>1261081620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What the FUCK mp3?  Can I use it to make my music sound better and is it compatible with ipod?</p></htmltext>
<tokenext>What the FUCK mp3 ?
Can I use it to make my music sound better and is it compatible with ipod ?</tokentext>
<sentencetext>What the FUCK mp3?
Can I use it to make my music sound better and is it compatible with ipod?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482044</id>
	<title>Re:Focus group...</title>
	<author>geekoid</author>
	<datestamp>1261058520000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p>That's just wrong and offensive. I can' not believe you would you would say something so neanderthall.</p><p>This is the modern age asshole, and we put TV's in the kitchen~</p><p>No TV in the kitchen, sheesh.</p></htmltext>
<tokenext>That 's just wrong and offensive .
I can ' not believe you would you would say something so neanderthall.This is the modern age asshole , and we put TV 's in the kitchen ~ No TV in the kitchen , sheesh .</tokentext>
<sentencetext>That's just wrong and offensive.
I can' not believe you would you would say something so neanderthall.This is the modern age asshole, and we put TV's in the kitchen~No TV in the kitchen, sheesh.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477586</id>
	<title>Re:Yes, of course</title>
	<author>BronsCon</author>
	<datestamp>1261082160000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p>So, DVD vs. Blu-Ray is pointless if I'm using eye-buds?</p></htmltext>
<tokenext>So , DVD vs. Blu-Ray is pointless if I 'm using eye-buds ?</tokentext>
<sentencetext>So, DVD vs. Blu-Ray is pointless if I'm using eye-buds?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477034</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477280</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261081080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Cataracts don't make you far-sighted, but do make vision more blurry or even completely dark in the center.</p></htmltext>
<tokenext>Cataracts do n't make you far-sighted , but do make vision more blurry or even completely dark in the center .</tokentext>
<sentencetext>Cataracts don't make you far-sighted, but do make vision more blurry or even completely dark in the center.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477786</id>
	<title>Re:Yes, of course</title>
	<author>clone53421</author>
	<datestamp>1261082820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Don&rsquo;t be ridiculous. Of course converting analog to digital will always be a lossy conversion, in any raster-based / time-sampled digital format (this obviously would not apply to vector-based formats, or to an exact Fourier representation of a finite number of simple sine waves).</p><p>The difference between a &ldquo;lossless&rdquo; and a &ldquo;lossy&rdquo; compression format is that one of them then discards even more information from that digital representation, and the other one does not.</p></htmltext>
<tokenext>Don    t be ridiculous .
Of course converting analog to digital will always be a lossy conversion , in any raster-based / time-sampled digital format ( this obviously would not apply to vector-based formats , or to an exact Fourier representation of a finite number of simple sine waves ) .The difference between a    lossless    and a    lossy    compression format is that one of them then discards even more information from that digital representation , and the other one does not .</tokentext>
<sentencetext>Don’t be ridiculous.
Of course converting analog to digital will always be a lossy conversion, in any raster-based / time-sampled digital format (this obviously would not apply to vector-based formats, or to an exact Fourier representation of a finite number of simple sine waves).The difference between a “lossless” and a “lossy” compression format is that one of them then discards even more information from that digital representation, and the other one does not.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477034</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479624</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1261046160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>...or low rate may just be "better" esthetically (like some old 128bit mp3s sounding better than the original CDs, 'cause what's what folks are used to).</p></htmltext>
<tokenext>...or low rate may just be " better " esthetically ( like some old 128bit mp3s sounding better than the original CDs , 'cause what 's what folks are used to ) .</tokentext>
<sentencetext>...or low rate may just be "better" esthetically (like some old 128bit mp3s sounding better than the original CDs, 'cause what's what folks are used to).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476270</id>
	<title>noise</title>
	<author>methano</author>
	<datestamp>1261077480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Lower bit rates can reduce noise if it's of the high frequency, snap, crackle, pop variety.  You get less information but it's more soothing.  Some people prefer lower quality to higher quality because the high frequency stuff is annoying.  One of the nice advantages of getting older is that they can really scrimp on quality and you can no longer tell the difference.</htmltext>
<tokenext>Lower bit rates can reduce noise if it 's of the high frequency , snap , crackle , pop variety .
You get less information but it 's more soothing .
Some people prefer lower quality to higher quality because the high frequency stuff is annoying .
One of the nice advantages of getting older is that they can really scrimp on quality and you can no longer tell the difference .</tokentext>
<sentencetext>Lower bit rates can reduce noise if it's of the high frequency, snap, crackle, pop variety.
You get less information but it's more soothing.
Some people prefer lower quality to higher quality because the high frequency stuff is annoying.
One of the nice advantages of getting older is that they can really scrimp on quality and you can no longer tell the difference.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480622</id>
	<title>if the compression is better</title>
	<author>recharged95</author>
	<datestamp>1261050420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I thought if the motion compensation algo is better at 9mbits, than at 16, then it could look better, especially if there's a lot of action. Can't remember if the MPEG4/H.264 specs allow one to change it.
<br>
<br>
The again, it's BBC, all the shows are a bunch of folks sitting around a coffee table drinking tea with static images in the background, talking slowly.<br> Or at least that's how they explained British TV on Family Guy. You will see a difference with bitrate in that case.</htmltext>
<tokenext>I thought if the motion compensation algo is better at 9mbits , than at 16 , then it could look better , especially if there 's a lot of action .
Ca n't remember if the MPEG4/H.264 specs allow one to change it .
The again , it 's BBC , all the shows are a bunch of folks sitting around a coffee table drinking tea with static images in the background , talking slowly .
Or at least that 's how they explained British TV on Family Guy .
You will see a difference with bitrate in that case .</tokentext>
<sentencetext>I thought if the motion compensation algo is better at 9mbits, than at 16, then it could look better, especially if there's a lot of action.
Can't remember if the MPEG4/H.264 specs allow one to change it.
The again, it's BBC, all the shows are a bunch of folks sitting around a coffee table drinking tea with static images in the background, talking slowly.
Or at least that's how they explained British TV on Family Guy.
You will see a difference with bitrate in that case.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482066</id>
	<title>Re:Summary rounding error</title>
	<author>geekoid</author>
	<datestamp>1261058760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In no practical matter is it almost 50\% regardless of your nitpic.</p></htmltext>
<tokenext>In no practical matter is it almost 50 \ % regardless of your nitpic .</tokentext>
<sentencetext>In no practical matter is it almost 50\% regardless of your nitpic.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476208</id>
	<title>of course</title>
	<author>Anonymous</author>
	<datestamp>1261077300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?</p></div></blockquote><p>Ever looked at mpeg2 vs h264?  That's not what happened here, but your question gets a huge Yes anyway.</p></div>
	</htmltext>
<tokenext>I got a good laugh off of this , but is it really possible to get better quality from a lower bitrate ? Ever looked at mpeg2 vs h264 ?
That 's not what happened here , but your question gets a huge Yes anyway .</tokentext>
<sentencetext>I got a good laugh off of this, but is it really possible to get better quality from a lower bitrate?Ever looked at mpeg2 vs h264?
That's not what happened here, but your question gets a huge Yes anyway.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476924</id>
	<title>Re:Summary rounding error</title>
	<author>MrEricSir</author>
	<datestamp>1261079820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>When they say "news for nerds" they mean computer nerds, not math nerds.</p></htmltext>
<tokenext>When they say " news for nerds " they mean computer nerds , not math nerds .</tokentext>
<sentencetext>When they say "news for nerds" they mean computer nerds, not math nerds.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478910</id>
	<title>Re:Yes</title>
	<author>Anonymous</author>
	<datestamp>1261043760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Additional passes do nothing for video quality.  All they let you do is accurately hit a desired average bitrate.  In broadcasting, the only thing you really care about is the maximum bitrate.</htmltext>
<tokenext>Additional passes do nothing for video quality .
All they let you do is accurately hit a desired average bitrate .
In broadcasting , the only thing you really care about is the maximum bitrate .</tokentext>
<sentencetext>Additional passes do nothing for video quality.
All they let you do is accurately hit a desired average bitrate.
In broadcasting, the only thing you really care about is the maximum bitrate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480616</id>
	<title>Re:Yes</title>
	<author>X0563511</author>
	<datestamp>1261050360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>you should compare h.264 to mpeg-2...</p><p>Big difference in quality and bitrate, both leaning heavily in h.264's favor.</p></htmltext>
<tokenext>you should compare h.264 to mpeg-2...Big difference in quality and bitrate , both leaning heavily in h.264 's favor .</tokentext>
<sentencetext>you should compare h.264 to mpeg-2...Big difference in quality and bitrate, both leaning heavily in h.264's favor.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476398</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476428</id>
	<title>Depends on the codec</title>
	<author>Anonymous</author>
	<datestamp>1261078080000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>1</modscore>
	<htmltext><p>If they've switched from MPEG-2 to MPEG-4, then yes, you can get equal or better quality at a lower bitrate.</p></htmltext>
<tokenext>If they 've switched from MPEG-2 to MPEG-4 , then yes , you can get equal or better quality at a lower bitrate .</tokentext>
<sentencetext>If they've switched from MPEG-2 to MPEG-4, then yes, you can get equal or better quality at a lower bitrate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481424</id>
	<title>Viewers Notice Bandwidth Cut</title>
	<author>aynoknman</author>
	<datestamp>1261055160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Pictures at 11:07</htmltext>
<tokenext>Pictures at 11 : 07</tokentext>
<sentencetext>Pictures at 11:07</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261078680000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>FTA: ""Even my wife can see a reduction in picture quality and she's got cataracts," wrote one. "</p></div><p>They must have a pretty big screen if she can see that difference from the kitchen.</p></div>
	</htmltext>
<tokenext>FTA : " " Even my wife can see a reduction in picture quality and she 's got cataracts , " wrote one .
" They must have a pretty big screen if she can see that difference from the kitchen .</tokentext>
<sentencetext>FTA: ""Even my wife can see a reduction in picture quality and she's got cataracts," wrote one.
"They must have a pretty big screen if she can see that difference from the kitchen.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476256</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476520</id>
	<title>Re:Yes</title>
	<author>Speare</author>
	<datestamp>1261078440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In addition, if your higher bitrate is clogging the net and stalling every few seconds, and the lower bitrate actually allows the audio and/or to be played in real time, then many people would say that is an <i>improvement</i> in quality although not necessarily on a frame-by-frame basis.</htmltext>
<tokenext>In addition , if your higher bitrate is clogging the net and stalling every few seconds , and the lower bitrate actually allows the audio and/or to be played in real time , then many people would say that is an improvement in quality although not necessarily on a frame-by-frame basis .</tokentext>
<sentencetext>In addition, if your higher bitrate is clogging the net and stalling every few seconds, and the lower bitrate actually allows the audio and/or to be played in real time, then many people would say that is an improvement in quality although not necessarily on a frame-by-frame basis.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478162</id>
	<title>Re:Focus group...</title>
	<author>wagnerrp</author>
	<datestamp>1261040820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>For example, you can get higher quality with CPU-intensive settings using H.264 5.1 Profile than you can with H.264 4.1 (what Blu-Ray's/HD DVDs use), at the same bitrate. You're giving up CPU cycles in decoding for lower video size</p></div><p>4.1 and 5.1 are levels, not profiles.  Levels define the minimum throughput and frame memory required for a decoder.  By running 5.1/unlimited, the only thing you get is the ability to crank up the number of reference frames for a quickly diminishing gain.  Note that affects memory consumption directly, and CPU usage hardly at all.</p><p><div class="quote"><p>x264 uses much more demanding settings. x264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.</p></div><p>x264 allows YOU to use much more demanding settings.  The defaults are actually fairly standard.  Furthermore, nearly all of those settings affect encoding performance, making little difference in decoding speed besides possibly breaking hardware decoders.  The two settings that make the most change in performance and compression are CABAC/CAVLC and slice count.  CABAC offers 25-30\% better compression for about 35\% more CPU for decoding, but considering the Blu-Ray spec requires player to support CABAC, nearly all disks using h264 encoding will use CABAC.  H264 offers parallel decoding through the concept of slices, areas of the video that are partitioned and encoded/decoded independently.  Bluray videos generally have six or more of these.  Using a single slice will noticeably improve compressibility, at the complete loss of parallelism.  A 20mbps single-sliced h264 video with CABAC will strain even an i7 with Turbo Boost enabled, while it will handle that 40mbps Bluray encode at around half load.</p><p>The only other explanation is that properly encoded, 40mbps for 1080p24 is just beyond the visual acuity limits of the average human.  The 20mbps video is closer to what you would expect out of an HDDVD, and back when that war was still going on, I recall one of the x264 devs (or maybe ffmpeg dev) claiming the additional bitrate afforded by Bluray went largely without gain, and the 30GB of HDDVD was plenty.</p></div>
	</htmltext>
<tokenext>For example , you can get higher quality with CPU-intensive settings using H.264 5.1 Profile than you can with H.264 4.1 ( what Blu-Ray 's/HD DVDs use ) , at the same bitrate .
You 're giving up CPU cycles in decoding for lower video size4.1 and 5.1 are levels , not profiles .
Levels define the minimum throughput and frame memory required for a decoder .
By running 5.1/unlimited , the only thing you get is the ability to crank up the number of reference frames for a quickly diminishing gain .
Note that affects memory consumption directly , and CPU usage hardly at all.x264 uses much more demanding settings .
x264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.x264 allows YOU to use much more demanding settings .
The defaults are actually fairly standard .
Furthermore , nearly all of those settings affect encoding performance , making little difference in decoding speed besides possibly breaking hardware decoders .
The two settings that make the most change in performance and compression are CABAC/CAVLC and slice count .
CABAC offers 25-30 \ % better compression for about 35 \ % more CPU for decoding , but considering the Blu-Ray spec requires player to support CABAC , nearly all disks using h264 encoding will use CABAC .
H264 offers parallel decoding through the concept of slices , areas of the video that are partitioned and encoded/decoded independently .
Bluray videos generally have six or more of these .
Using a single slice will noticeably improve compressibility , at the complete loss of parallelism .
A 20mbps single-sliced h264 video with CABAC will strain even an i7 with Turbo Boost enabled , while it will handle that 40mbps Bluray encode at around half load.The only other explanation is that properly encoded , 40mbps for 1080p24 is just beyond the visual acuity limits of the average human .
The 20mbps video is closer to what you would expect out of an HDDVD , and back when that war was still going on , I recall one of the x264 devs ( or maybe ffmpeg dev ) claiming the additional bitrate afforded by Bluray went largely without gain , and the 30GB of HDDVD was plenty .</tokentext>
<sentencetext>For example, you can get higher quality with CPU-intensive settings using H.264 5.1 Profile than you can with H.264 4.1 (what Blu-Ray's/HD DVDs use), at the same bitrate.
You're giving up CPU cycles in decoding for lower video size4.1 and 5.1 are levels, not profiles.
Levels define the minimum throughput and frame memory required for a decoder.
By running 5.1/unlimited, the only thing you get is the ability to crank up the number of reference frames for a quickly diminishing gain.
Note that affects memory consumption directly, and CPU usage hardly at all.x264 uses much more demanding settings.
x264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.x264 allows YOU to use much more demanding settings.
The defaults are actually fairly standard.
Furthermore, nearly all of those settings affect encoding performance, making little difference in decoding speed besides possibly breaking hardware decoders.
The two settings that make the most change in performance and compression are CABAC/CAVLC and slice count.
CABAC offers 25-30\% better compression for about 35\% more CPU for decoding, but considering the Blu-Ray spec requires player to support CABAC, nearly all disks using h264 encoding will use CABAC.
H264 offers parallel decoding through the concept of slices, areas of the video that are partitioned and encoded/decoded independently.
Bluray videos generally have six or more of these.
Using a single slice will noticeably improve compressibility, at the complete loss of parallelism.
A 20mbps single-sliced h264 video with CABAC will strain even an i7 with Turbo Boost enabled, while it will handle that 40mbps Bluray encode at around half load.The only other explanation is that properly encoded, 40mbps for 1080p24 is just beyond the visual acuity limits of the average human.
The 20mbps video is closer to what you would expect out of an HDDVD, and back when that war was still going on, I recall one of the x264 devs (or maybe ffmpeg dev) claiming the additional bitrate afforded by Bluray went largely without gain, and the 30GB of HDDVD was plenty.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481212</id>
	<title>Re:Crap HD Quality</title>
	<author>Mia'cova</author>
	<datestamp>1261053780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I just switched to comcast after a year of OTA HDTV. It's a shame because the quality has taken a huge hit. It's still a good tradeoff as my signal would cut out every 5-10 minutes for a few seconds with OTA. But even so, now I just feel like torrenting half the stuff I watch because the comcast HD feed isn't as good as the 720p downloads. Not to mention the volume of ads on broadcast TV make me want to put a gun to my head...</p></htmltext>
<tokenext>I just switched to comcast after a year of OTA HDTV .
It 's a shame because the quality has taken a huge hit .
It 's still a good tradeoff as my signal would cut out every 5-10 minutes for a few seconds with OTA .
But even so , now I just feel like torrenting half the stuff I watch because the comcast HD feed is n't as good as the 720p downloads .
Not to mention the volume of ads on broadcast TV make me want to put a gun to my head.. .</tokentext>
<sentencetext>I just switched to comcast after a year of OTA HDTV.
It's a shame because the quality has taken a huge hit.
It's still a good tradeoff as my signal would cut out every 5-10 minutes for a few seconds with OTA.
But even so, now I just feel like torrenting half the stuff I watch because the comcast HD feed isn't as good as the 720p downloads.
Not to mention the volume of ads on broadcast TV make me want to put a gun to my head...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476256</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261077480000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>FTA: ""Even my wife can see a reduction in picture quality and she's got cataracts," wrote one. "</htmltext>
<tokenext>FTA : " " Even my wife can see a reduction in picture quality and she 's got cataracts , " wrote one .
"</tokentext>
<sentencetext>FTA: ""Even my wife can see a reduction in picture quality and she's got cataracts," wrote one.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479348</id>
	<title>BBC got away with it on BBC1</title>
	<author>Anonymous</author>
	<datestamp>1261045320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Earlier this year the BBC reduced BBC1 SD bitrate by about the same amount, by switching from 4.5Mbit fixed rate to variable rate. No-one noticed because most of time they just didn't need that bitrate. We actually have higher average quality now because the bitrate can climb well above 4.5 on demanding scenes. It was always annoying how much space BBC1 recordings needed on a PVR at the old rates and how it buggered up other channels in the mux.</p><p>That may be why they thought they could get away with dropping the HD rate, at least in management.</p></htmltext>
<tokenext>Earlier this year the BBC reduced BBC1 SD bitrate by about the same amount , by switching from 4.5Mbit fixed rate to variable rate .
No-one noticed because most of time they just did n't need that bitrate .
We actually have higher average quality now because the bitrate can climb well above 4.5 on demanding scenes .
It was always annoying how much space BBC1 recordings needed on a PVR at the old rates and how it buggered up other channels in the mux.That may be why they thought they could get away with dropping the HD rate , at least in management .</tokentext>
<sentencetext>Earlier this year the BBC reduced BBC1 SD bitrate by about the same amount, by switching from 4.5Mbit fixed rate to variable rate.
No-one noticed because most of time they just didn't need that bitrate.
We actually have higher average quality now because the bitrate can climb well above 4.5 on demanding scenes.
It was always annoying how much space BBC1 recordings needed on a PVR at the old rates and how it buggered up other channels in the mux.That may be why they thought they could get away with dropping the HD rate, at least in management.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476232</id>
	<title>Re:Yes</title>
	<author>Bakkster</author>
	<datestamp>1261077360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>In other words, lower bitrate can be better, but only if you compare to shitty and inefficient compression.</p></htmltext>
<tokenext>In other words , lower bitrate can be better , but only if you compare to shitty and inefficient compression .</tokentext>
<sentencetext>In other words, lower bitrate can be better, but only if you compare to shitty and inefficient compression.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142</id>
	<title>Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261077060000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>...of blind retards.</p></htmltext>
<tokenext>...of blind retards .</tokentext>
<sentencetext>...of blind retards.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482840</id>
	<title>Re:Crap HD Quality</title>
	<author>mattsday</author>
	<datestamp>1261064100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I get the NFL here in the UK in HD (mostly) and the picture quality is usually of good quality. Sounds like a problem with the decoding or something your local station is doing maybe?</p></htmltext>
<tokenext>I get the NFL here in the UK in HD ( mostly ) and the picture quality is usually of good quality .
Sounds like a problem with the decoding or something your local station is doing maybe ?</tokentext>
<sentencetext>I get the NFL here in the UK in HD (mostly) and the picture quality is usually of good quality.
Sounds like a problem with the decoding or something your local station is doing maybe?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476672</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481804</id>
	<title>Re:Yes, of course</title>
	<author>pla</author>
	<datestamp>1261057080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>If you use those same 3 megabytes to store a lossy jpeg, you can store a lot more detail in the same file space</i> <br>
<br>
Absolutely true.<br>
<br>
Now just let me know when I can realistically have a system that handles lossy HD streams at 2.97 <b>giga</b>bits per
second, at a price people other than Billy G can afford, and I'll gladly upgrade from the crap we have now.<br>
<br>
Until then, apples and oranges.  Yes, you can store more <i>useful</i> information in a lossy stream than in a lossless
stream <b>at the same bitrate</b>.  But simply put, we don't use lossy compression for that purpose.  We use it so BluRay
looks halfway decent at a mere 1.35\% (40Mbps) of the raw size.</htmltext>
<tokenext>If you use those same 3 megabytes to store a lossy jpeg , you can store a lot more detail in the same file space Absolutely true .
Now just let me know when I can realistically have a system that handles lossy HD streams at 2.97 gigabits per second , at a price people other than Billy G can afford , and I 'll gladly upgrade from the crap we have now .
Until then , apples and oranges .
Yes , you can store more useful information in a lossy stream than in a lossless stream at the same bitrate .
But simply put , we do n't use lossy compression for that purpose .
We use it so BluRay looks halfway decent at a mere 1.35 \ % ( 40Mbps ) of the raw size .</tokentext>
<sentencetext>If you use those same 3 megabytes to store a lossy jpeg, you can store a lot more detail in the same file space 

Absolutely true.
Now just let me know when I can realistically have a system that handles lossy HD streams at 2.97 gigabits per
second, at a price people other than Billy G can afford, and I'll gladly upgrade from the crap we have now.
Until then, apples and oranges.
Yes, you can store more useful information in a lossy stream than in a lossless
stream at the same bitrate.
But simply put, we don't use lossy compression for that purpose.
We use it so BluRay
looks halfway decent at a mere 1.35\% (40Mbps) of the raw size.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477034</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476222</id>
	<title>Their new algorithm?</title>
	<author>seven of five</author>
	<datestamp>1261077300000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext>They just remove the naughty bits.</htmltext>
<tokenext>They just remove the naughty bits .</tokentext>
<sentencetext>They just remove the naughty bits.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481118</id>
	<title>Re:Crap HD Quality</title>
	<author>nuckfuts</author>
	<datestamp>1261053180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I used to have a friend who could spot the two little circles in the top right of a movie in the theater telling the projectionist to change the reel. Once he saw them the movies were never the same again.</p></div><p>Yep. Years ago I started noticing those two flashes in the top right corner of the movie screen. I've never stopped noticing them. The people sitting with me are oblivious.</p></div>
	</htmltext>
<tokenext>I used to have a friend who could spot the two little circles in the top right of a movie in the theater telling the projectionist to change the reel .
Once he saw them the movies were never the same again.Yep .
Years ago I started noticing those two flashes in the top right corner of the movie screen .
I 've never stopped noticing them .
The people sitting with me are oblivious .</tokentext>
<sentencetext>I used to have a friend who could spot the two little circles in the top right of a movie in the theater telling the projectionist to change the reel.
Once he saw them the movies were never the same again.Yep.
Years ago I started noticing those two flashes in the top right corner of the movie screen.
I've never stopped noticing them.
The people sitting with me are oblivious.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477364</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261081440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You don't really know what levels in H.264 are about. The only difference between level 4.1 and level 5.1 is maximum allowed resolution and framerate (= macroblocks per second) and maximum bitrate. The maximum of 62.5 Mb/s plus whatever the buffer size on the device is is more than enough for high quality 1080p videos. The reason why x264 encodes are good at way lower bitrates than blu-ray uses is simply that x264 uses very sophisticated analysis and makes use of various psychovisual optimizations. This takes more time on encoding, but doesn't influence decoding complexity in any meaningful way. In fact since you can get away with lower bitrates when using x264 the resulting files are easier to decode. The reason for this is that the entropy coding H.264 uses (CABAC) takes a significant part of the decoding time that scales linearly with bitrate.</p><p>So</p><p><div class="quote"><p>x264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.</p></div><p>is flat out wrong.</p></div>
	</htmltext>
<tokenext>You do n't really know what levels in H.264 are about .
The only difference between level 4.1 and level 5.1 is maximum allowed resolution and framerate ( = macroblocks per second ) and maximum bitrate .
The maximum of 62.5 Mb/s plus whatever the buffer size on the device is is more than enough for high quality 1080p videos .
The reason why x264 encodes are good at way lower bitrates than blu-ray uses is simply that x264 uses very sophisticated analysis and makes use of various psychovisual optimizations .
This takes more time on encoding , but does n't influence decoding complexity in any meaningful way .
In fact since you can get away with lower bitrates when using x264 the resulting files are easier to decode .
The reason for this is that the entropy coding H.264 uses ( CABAC ) takes a significant part of the decoding time that scales linearly with bitrate.Sox264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.is flat out wrong .</tokentext>
<sentencetext>You don't really know what levels in H.264 are about.
The only difference between level 4.1 and level 5.1 is maximum allowed resolution and framerate (= macroblocks per second) and maximum bitrate.
The maximum of 62.5 Mb/s plus whatever the buffer size on the device is is more than enough for high quality 1080p videos.
The reason why x264 encodes are good at way lower bitrates than blu-ray uses is simply that x264 uses very sophisticated analysis and makes use of various psychovisual optimizations.
This takes more time on encoding, but doesn't influence decoding complexity in any meaningful way.
In fact since you can get away with lower bitrates when using x264 the resulting files are easier to decode.
The reason for this is that the entropy coding H.264 uses (CABAC) takes a significant part of the decoding time that scales linearly with bitrate.Sox264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.is flat out wrong.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212</id>
	<title>Summary rounding error</title>
	<author>Anonymous</author>
	<datestamp>1261077300000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>Nitpick: So 39\% is "almost 50\%"?? I would have called that "almost 40\%". Then again that is a<nobr> <wbr></nobr>/. summary.</htmltext>
<tokenext>Nitpick : So 39 \ % is " almost 50 \ % " ? ?
I would have called that " almost 40 \ % " .
Then again that is a / .
summary .</tokentext>
<sentencetext>Nitpick: So 39\% is "almost 50\%"??
I would have called that "almost 40\%".
Then again that is a /.
summary.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476562</id>
	<title>Re:Crap HD Quality</title>
	<author>Anonymous</author>
	<datestamp>1261078560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>But they're only circles for matted prints.  If it's anamorphic, the circles will be stretched into ellipses.  Irrelevant, perhaps, as you can tell from the aspect ratio (2.35:1 is anamorphic, 1.85:1 is matted), but it certainly provides conclusive verification.</p></htmltext>
<tokenext>But they 're only circles for matted prints .
If it 's anamorphic , the circles will be stretched into ellipses .
Irrelevant , perhaps , as you can tell from the aspect ratio ( 2.35 : 1 is anamorphic , 1.85 : 1 is matted ) , but it certainly provides conclusive verification .</tokentext>
<sentencetext>But they're only circles for matted prints.
If it's anamorphic, the circles will be stretched into ellipses.
Irrelevant, perhaps, as you can tell from the aspect ratio (2.35:1 is anamorphic, 1.85:1 is matted), but it certainly provides conclusive verification.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478394</id>
	<title>Re:Focus group...</title>
	<author>Binary Boy</author>
	<datestamp>1261041780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Actually, it is possible with some products to get higher quality out of the same or lower bitrate when you're using a better encoder - just because they all output bitstreams that comply with the same spec doesn't mean they are all equal, even when given comparable parameters and the same input. Not knowing what encoders BBC was using, and which they switched to, it's hard to say, but there are certainly better and worse encoders, particularly in MPEG-2 (where there's a long history and lot of variety).</p><p>That said, I'd not expect a something as radical as a 50\% bitrate reduction to result in better encodes unless the original encoder was the original iDVD - the differences are rarely that extreme.</p></htmltext>
<tokenext>Actually , it is possible with some products to get higher quality out of the same or lower bitrate when you 're using a better encoder - just because they all output bitstreams that comply with the same spec does n't mean they are all equal , even when given comparable parameters and the same input .
Not knowing what encoders BBC was using , and which they switched to , it 's hard to say , but there are certainly better and worse encoders , particularly in MPEG-2 ( where there 's a long history and lot of variety ) .That said , I 'd not expect a something as radical as a 50 \ % bitrate reduction to result in better encodes unless the original encoder was the original iDVD - the differences are rarely that extreme .</tokentext>
<sentencetext>Actually, it is possible with some products to get higher quality out of the same or lower bitrate when you're using a better encoder - just because they all output bitstreams that comply with the same spec doesn't mean they are all equal, even when given comparable parameters and the same input.
Not knowing what encoders BBC was using, and which they switched to, it's hard to say, but there are certainly better and worse encoders, particularly in MPEG-2 (where there's a long history and lot of variety).That said, I'd not expect a something as radical as a 50\% bitrate reduction to result in better encodes unless the original encoder was the original iDVD - the differences are rarely that extreme.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476190</id>
	<title>Of course it is possible</title>
	<author>godrik</author>
	<datestamp>1261077240000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>but is it really possible to get better quality from a lower bitrate?</p></div><p>If you are changing the compression algorithm of course it is possible. In H264, there are a lot of compression possibilities which are not used by the compression algorithm but which will be recognized by the decompression algorithm.</p></div>
	</htmltext>
<tokenext>but is it really possible to get better quality from a lower bitrate ? If you are changing the compression algorithm of course it is possible .
In H264 , there are a lot of compression possibilities which are not used by the compression algorithm but which will be recognized by the decompression algorithm .</tokentext>
<sentencetext>but is it really possible to get better quality from a lower bitrate?If you are changing the compression algorithm of course it is possible.
In H264, there are a lot of compression possibilities which are not used by the compression algorithm but which will be recognized by the decompression algorithm.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476278</id>
	<title>It is possible, but I don't think they did.</title>
	<author>Anonymous</author>
	<datestamp>1261077540000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm far from an expert, but my understanding is that to a limited extent, you can make a trade-off between the bitrate and encoding/decoding time. H.264/MPEG-4 AVC is superior to older codecs, generally having both better visual quality and a lower bitrate, but it requires much more time to encode and requires more powerful hardware to decode the stream.</p><p>But my very loose understanding is that all they did was lower the bitrate and maybe conducted a test to see if some random idiots could tell the difference with ideal samples.</p></htmltext>
<tokenext>I 'm far from an expert , but my understanding is that to a limited extent , you can make a trade-off between the bitrate and encoding/decoding time .
H.264/MPEG-4 AVC is superior to older codecs , generally having both better visual quality and a lower bitrate , but it requires much more time to encode and requires more powerful hardware to decode the stream.But my very loose understanding is that all they did was lower the bitrate and maybe conducted a test to see if some random idiots could tell the difference with ideal samples .</tokentext>
<sentencetext>I'm far from an expert, but my understanding is that to a limited extent, you can make a trade-off between the bitrate and encoding/decoding time.
H.264/MPEG-4 AVC is superior to older codecs, generally having both better visual quality and a lower bitrate, but it requires much more time to encode and requires more powerful hardware to decode the stream.But my very loose understanding is that all they did was lower the bitrate and maybe conducted a test to see if some random idiots could tell the difference with ideal samples.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476210</id>
	<title>Bitrate vs. Quality</title>
	<author>jandrese</author>
	<datestamp>1261077300000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>It's not impossible to get better results out of lower bitrates, but you have to pay the penalty elsewhere, typically in encode/decode complexity.
<br> <br>
If your decode hardware is fixed (it's generic HDTV hardware), then there is much less room for improvement, and half the bitrate is an enormous drop.  It's no surprise that the BBC viewers complained.</htmltext>
<tokenext>It 's not impossible to get better results out of lower bitrates , but you have to pay the penalty elsewhere , typically in encode/decode complexity .
If your decode hardware is fixed ( it 's generic HDTV hardware ) , then there is much less room for improvement , and half the bitrate is an enormous drop .
It 's no surprise that the BBC viewers complained .</tokentext>
<sentencetext>It's not impossible to get better results out of lower bitrates, but you have to pay the penalty elsewhere, typically in encode/decode complexity.
If your decode hardware is fixed (it's generic HDTV hardware), then there is much less room for improvement, and half the bitrate is an enormous drop.
It's no surprise that the BBC viewers complained.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479608</id>
	<title>Re:Bitrate vs. Quality</title>
	<author>Anonymous</author>
	<datestamp>1261046100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>While newer codecs usually have higher computational cost, and you usually pay a price for higher quality per bitrate, this is not always the case. A better understanding of what you are coding (i.e.: better mathematical models) provide means to achieve better quality per bitrate at the same computational cost. See for example "AM Tourapis -Enhanced predictive zonal search for single and multiple frame motion estimation" (actually it has a slight penalty on quality, but you can compensate it by better spending the remaining computer power on other places).</p></htmltext>
<tokenext>While newer codecs usually have higher computational cost , and you usually pay a price for higher quality per bitrate , this is not always the case .
A better understanding of what you are coding ( i.e .
: better mathematical models ) provide means to achieve better quality per bitrate at the same computational cost .
See for example " AM Tourapis -Enhanced predictive zonal search for single and multiple frame motion estimation " ( actually it has a slight penalty on quality , but you can compensate it by better spending the remaining computer power on other places ) .</tokentext>
<sentencetext>While newer codecs usually have higher computational cost, and you usually pay a price for higher quality per bitrate, this is not always the case.
A better understanding of what you are coding (i.e.
: better mathematical models) provide means to achieve better quality per bitrate at the same computational cost.
See for example "AM Tourapis -Enhanced predictive zonal search for single and multiple frame motion estimation" (actually it has a slight penalty on quality, but you can compensate it by better spending the remaining computer power on other places).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476210</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30485412</id>
	<title>Re:A better model beats higher bitrate every time</title>
	<author>Anonymous</author>
	<datestamp>1261140180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Please mod parent up.</p><p>The "discernible difference" measuring stick is difficult to use. Add to this the complexity of measuring *unwanted* discernible difference.</p></htmltext>
<tokenext>Please mod parent up.The " discernible difference " measuring stick is difficult to use .
Add to this the complexity of measuring * unwanted * discernible difference .</tokentext>
<sentencetext>Please mod parent up.The "discernible difference" measuring stick is difficult to use.
Add to this the complexity of measuring *unwanted* discernible difference.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476290</id>
	<title>It depends on the material</title>
	<author>Anonymous</author>
	<datestamp>1261077540000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>If you're watching a soap opera, you only need to see a few frames per week to follow the story. If you are watching a live sports event with a lot of action, most people will notice every dropped frame and compression artifact (I've noticed myself while watching the Olympics via satellite feed.) Methinks they did the testing on a relatively static video. Video compression works by (among other methods) creating a key frame, then sending diffs off that key frame for several frames. If every frame is completely different, compression does not work well.</htmltext>
<tokenext>If you 're watching a soap opera , you only need to see a few frames per week to follow the story .
If you are watching a live sports event with a lot of action , most people will notice every dropped frame and compression artifact ( I 've noticed myself while watching the Olympics via satellite feed .
) Methinks they did the testing on a relatively static video .
Video compression works by ( among other methods ) creating a key frame , then sending diffs off that key frame for several frames .
If every frame is completely different , compression does not work well .</tokentext>
<sentencetext>If you're watching a soap opera, you only need to see a few frames per week to follow the story.
If you are watching a live sports event with a lot of action, most people will notice every dropped frame and compression artifact (I've noticed myself while watching the Olympics via satellite feed.
) Methinks they did the testing on a relatively static video.
Video compression works by (among other methods) creating a key frame, then sending diffs off that key frame for several frames.
If every frame is completely different, compression does not work well.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482152</id>
	<title>Re:Crap HD Quality</title>
	<author>smchris</author>
	<datestamp>1261059180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><em>OTA is even better but cable is still awfully good.</em></p><p>Oh, boy!  I smell an opening for<nobr> <wbr></nobr>./'s weekly debate on the merits of MythTV!!</p></htmltext>
<tokenext>OTA is even better but cable is still awfully good.Oh , boy !
I smell an opening for ./ 's weekly debate on the merits of MythTV !
!</tokentext>
<sentencetext>OTA is even better but cable is still awfully good.Oh, boy!
I smell an opening for ./'s weekly debate on the merits of MythTV!
!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476672</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478904</id>
	<title>Re:Focus group...</title>
	<author>Anonymous</author>
	<datestamp>1261043760000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>These are the Reference frame limits in Level 4.1</p><p>Resolution | no. ref<br>-----------|---------<br>
&nbsp; 1280x544  |    12<br>
&nbsp; 1280x720  |     9<br>
&nbsp; 1920x800  |     5<br>
&nbsp; 1920x816  |     5<br>
&nbsp; 1920x1080 |     4</p><p>If none of the resolutions above match your source, use the following equation to work it out for yourself:</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 8388608<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_</p><p>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; (width x height)</p><p>However, I've seen Level 5.1 encodes with 16 ref frames at full 1920x1200.</p></htmltext>
<tokenext>These are the Reference frame limits in Level 4.1Resolution | no .
ref----------- | ---------   1280x544 | 12   1280x720 | 9   1920x800 | 5   1920x816 | 5   1920x1080 | 4If none of the resolutions above match your source , use the following equation to work it out for yourself :                           8388608                 \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _ \ _                   ( width x height ) However , I 've seen Level 5.1 encodes with 16 ref frames at full 1920x1200 .</tokentext>
<sentencetext>These are the Reference frame limits in Level 4.1Resolution | no.
ref-----------|---------
  1280x544  |    12
  1280x720  |     9
  1920x800  |     5
  1920x816  |     5
  1920x1080 |     4If none of the resolutions above match your source, use the following equation to work it out for yourself:
                          8388608
                \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
                  (width x height)However, I've seen Level 5.1 encodes with 16 ref frames at full 1920x1200.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477364</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476668</id>
	<title>digital movie theaters don't have them and they ha</title>
	<author>Anonymous</author>
	<datestamp>1261078860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>digital movie theaters don't have them and they have better video there as well.</p></htmltext>
<tokenext>digital movie theaters do n't have them and they have better video there as well .</tokentext>
<sentencetext>digital movie theaters don't have them and they have better video there as well.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479948</id>
	<title>Re:Yes</title>
	<author>TheSync</author>
	<datestamp>1261047600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>You can also get better compression by specifying a more sophisticated compression method within the same codec</i></p><p>I concur.  A few years ago, HD with MPEG-2 only looked OK at 18 Mbps with the encoders of the time.  Today, it looks OK at 12 Mbps with the most modern encoders.</p><p>It is likely that H.264 will also see a similar decrease in bitrate at comparable quality.  It is mainly a matter of people learning how to use the different encoding tools within the codec, and having the CPU and memory to implement them.</p></htmltext>
<tokenext>You can also get better compression by specifying a more sophisticated compression method within the same codecI concur .
A few years ago , HD with MPEG-2 only looked OK at 18 Mbps with the encoders of the time .
Today , it looks OK at 12 Mbps with the most modern encoders.It is likely that H.264 will also see a similar decrease in bitrate at comparable quality .
It is mainly a matter of people learning how to use the different encoding tools within the codec , and having the CPU and memory to implement them .</tokentext>
<sentencetext>You can also get better compression by specifying a more sophisticated compression method within the same codecI concur.
A few years ago, HD with MPEG-2 only looked OK at 18 Mbps with the encoders of the time.
Today, it looks OK at 12 Mbps with the most modern encoders.It is likely that H.264 will also see a similar decrease in bitrate at comparable quality.
It is mainly a matter of people learning how to use the different encoding tools within the codec, and having the CPU and memory to implement them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477034</id>
	<title>Re:Yes, of course</title>
	<author>trb</author>
	<datestamp>1261080120000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>Lossless compression also works by throwing away data.  In a simple case, if you have a still image and you store it in a file that's 1000x1000 pixels and 24 bits deep with 8 bits each of red, green, and blue, you store that uncompressed in 3 megabytes.  24 bits of color isn't infinite, it's a palette of 16.77 million colors.  And you're not saving every micron of the image.  You are dicing the image into 1000x1000.  If you are taking a picture of a scene that's 10 meters by 10 meters, you are stuffing a square 10x10 mm into each pixel.  And also, your recorded image isn't perfect anyway, it's not perfectly focused and color reproduction is not exact.  Information is lost.
<p>
If you use those same 3 megabytes to store a lossy jpeg, you can store a lot more detail in the same file space - at typical compression rates, it might be 5-10 times more detail.  I am often puzzled by folks who hate lossy and love lossless, because lossless isn't simply lossless, it's smarter about what it chooses to lose.
</p><p>
I understand that the process of uncompressing and recompressing a lossy image is a lossy process, but we're not talking about multiple recompressions here, we're talking about one cycle.  This is true for both broadcast video and for playing back your personal music.  And especially if you listen with earbuds, it's silly to worry about audio compression loss, since the earbuds are very lossy.  I know that this is a discussion of video, but the same rules apply.</p></htmltext>
<tokenext>Lossless compression also works by throwing away data .
In a simple case , if you have a still image and you store it in a file that 's 1000x1000 pixels and 24 bits deep with 8 bits each of red , green , and blue , you store that uncompressed in 3 megabytes .
24 bits of color is n't infinite , it 's a palette of 16.77 million colors .
And you 're not saving every micron of the image .
You are dicing the image into 1000x1000 .
If you are taking a picture of a scene that 's 10 meters by 10 meters , you are stuffing a square 10x10 mm into each pixel .
And also , your recorded image is n't perfect anyway , it 's not perfectly focused and color reproduction is not exact .
Information is lost .
If you use those same 3 megabytes to store a lossy jpeg , you can store a lot more detail in the same file space - at typical compression rates , it might be 5-10 times more detail .
I am often puzzled by folks who hate lossy and love lossless , because lossless is n't simply lossless , it 's smarter about what it chooses to lose .
I understand that the process of uncompressing and recompressing a lossy image is a lossy process , but we 're not talking about multiple recompressions here , we 're talking about one cycle .
This is true for both broadcast video and for playing back your personal music .
And especially if you listen with earbuds , it 's silly to worry about audio compression loss , since the earbuds are very lossy .
I know that this is a discussion of video , but the same rules apply .</tokentext>
<sentencetext>Lossless compression also works by throwing away data.
In a simple case, if you have a still image and you store it in a file that's 1000x1000 pixels and 24 bits deep with 8 bits each of red, green, and blue, you store that uncompressed in 3 megabytes.
24 bits of color isn't infinite, it's a palette of 16.77 million colors.
And you're not saving every micron of the image.
You are dicing the image into 1000x1000.
If you are taking a picture of a scene that's 10 meters by 10 meters, you are stuffing a square 10x10 mm into each pixel.
And also, your recorded image isn't perfect anyway, it's not perfectly focused and color reproduction is not exact.
Information is lost.
If you use those same 3 megabytes to store a lossy jpeg, you can store a lot more detail in the same file space - at typical compression rates, it might be 5-10 times more detail.
I am often puzzled by folks who hate lossy and love lossless, because lossless isn't simply lossless, it's smarter about what it chooses to lose.
I understand that the process of uncompressing and recompressing a lossy image is a lossy process, but we're not talking about multiple recompressions here, we're talking about one cycle.
This is true for both broadcast video and for playing back your personal music.
And especially if you listen with earbuds, it's silly to worry about audio compression loss, since the earbuds are very lossy.
I know that this is a discussion of video, but the same rules apply.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476196</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476154</id>
	<title>Better quality from a lower bitrate?</title>
	<author>Anonymous</author>
	<datestamp>1261077120000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>-1</modscore>
	<htmltext><p><div class="quote"><p>is it really possible to get better quality from a lower bitrate?</p></div><p>Yes.  Next question.</p></div>
	</htmltext>
<tokenext>is it really possible to get better quality from a lower bitrate ? Yes .
Next question .</tokentext>
<sentencetext>is it really possible to get better quality from a lower bitrate?Yes.
Next question.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476176</id>
	<title>So they starting to act like comcast cable with th</title>
	<author>Anonymous</author>
	<datestamp>1261077180000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>0</modscore>
	<htmltext><p>So they starting to act like comcast cable with there compressed HD.</p></htmltext>
<tokenext>So they starting to act like comcast cable with there compressed HD .</tokentext>
<sentencetext>So they starting to act like comcast cable with there compressed HD.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478162
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477280
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476668
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476672
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482090
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477330
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476562
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30526260
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482538
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476196
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477034
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477586
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479052
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482044
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479154
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482758
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476290
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481948
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30484294
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476294
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477328
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476672
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482152
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477840
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30488252
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477088
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477574
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30485386
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477436
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476672
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482840
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476222
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477110
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476502
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480440
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477804
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482222
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30491342
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476190
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477392
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477364
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478904
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476222
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476968
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479234
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480108
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479624
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476924
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477842
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476382
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482632
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476502
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478318
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479018
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30485412
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479948
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476196
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477034
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477786
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476196
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477034
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481804
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476676
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479840
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476520
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476264
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476658
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478616
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476224
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482580
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476210
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479608
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481146
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476232
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481118
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478394
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480162
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476196
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476408
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478764
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481212
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477364
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478830
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482066
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477170
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482134
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_17_187248_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476398
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480616
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476142
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476580
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478394
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478162
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477364
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478830
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478904
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479052
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476256
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476590
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477088
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477804
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479840
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482538
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477280
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482044
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476294
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476176
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476502
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480440
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478318
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476190
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477392
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476170
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482632
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476264
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476658
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476368
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477328
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479948
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482222
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477840
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477330
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479018
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476382
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477574
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479624
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476520
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476330
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476148
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476676
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478910
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476232
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476398
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480616
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476430
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476290
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481948
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30484294
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476288
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481146
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30526260
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478886
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480108
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476672
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482152
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482840
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482090
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482758
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479154
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481212
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477170
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476562
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479234
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481118
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30488252
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482134
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476668
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476578
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477436
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30485412
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478616
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480162
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476196
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476408
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477034
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477586
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30481804
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477786
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476200
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476428
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476222
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476968
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477110
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476212
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30491342
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30478764
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476924
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476564
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482066
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480618
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30485386
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30477842
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476224
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30482580
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30480786
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476210
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30479608
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_17_187248.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_17_187248.30476348
</commentlist>
</conversation>
