Trackball Explorers still go for hundreds of dollars a piece on eBay to this day. And there's an open source project called Ploopy that aims to replicate it, though not quite as well as I'd hoped. It would be great if they started making the Trackball Explorer again. The plastic on them is starting to get brittle enough that simply taking them apart to mix and match good parts is a risk now, as they may not even go back together again. Even the screw hole posts are breaking just from age. The market for them may not be huge, but I feel they'd be pretty loyal, considering the eBay throughput on these things. I'd also love a new Natural Keyboard v1 design.

bwhahahahaha

Still said Valve right on the product right from day one regardless of whether or not you remember properly if the Valve intro video was in the first release. The point is, Valve made the game, so buddy couldn't have paid full price for the game before Valve existed.

You paid full price before Valve even existed? That's quite the feat.

The option of obtaining a refund when an event significantly changes (such as a key band member getting sick or injured and needing a substitute) is higher on my priority list than this. Most people won't care and will still go and enjoy the show. In some cases I'd rather have the option of returning the tickets due to a show no longer being what I paid for, especially since reselling is a gamble. Spending $400 on tickets I no longer want but am stuck with, which would require another $600 in travel and acommodations in order to use even though I no longer want to use them, is a bit of a kick in the nuts. Frankly, refunds should be allowed for any reason. If I don't want them anymore, I don't want them anymore. *You* sell them to someone else, as they're tickets to your show. Shouldn't be my burden to find someone else to take them off my hands.

I've had WinRAR's recovery volumes save my data at least a few times over the many years I used it. 7zip's interface could learn a few lessons from WinRAR's, too. 7zip typically gets a better compression ratio, but WinRAR's no slouch. With how cheap storage is this has kind of become moot, anyway, but still. hehe.

I do not want seven different modes all showing me different amounts of brightness and colour temperatures. The very idea is silly. All I want from a TV is to be shown what I'm supposed to be seeing, as close as it is capable of getting to the reference monitors used in production of TV shows and movies. They all use the same calibration targets, and we should be using them for our displays, too. So, it should come calibrated for the same D65 white point as those reference monitors are straight from the factory. I could be mistaken, but I think the SDR white standard is 100 nits, and so it should show me 100-nit whites with SDR media. I've been calibrating my TVs and computer monitors to show 100 nits for SDR whites anyway, as I thought that was what I read the standard was. If it is an HDR set it should be capable of 1000-nit whites, as probably the majority of HDR media uses that 1000-nit target. I know a smaller amount of HDR media uses a 4000-nit target. I'm undecided as to how that should be handled, as I know there aren't a lot of TVs that can go that bright yet. But I'd be happy with properly handling 1000-nit HDR media and showing me the amount of brightness I'm supposed to be seeing with that media, as well as it can. I know the ability to reproduce that level of brightness can depend on the percentage of the screen that's supposed to be that bright, with different screen technologies having different capabilities in that exercise.

I got a QD-OLED computer monitor in the middle of last year, and I love it. Now I also want to get a QD-OLED TV. I understand that at the moment they're not capable of giving full brightness with the whole screen filled, which I believe is mainly due to handling the amount of heat involved, as I understand it. So it could be some time before that situation improves with that screen tech. But they're capable of being very, very bright with smaller regions being asked to show white. It is so much nicer to look at than any of the various LCD displays and TVs I've had. Perhaps micro LED will not have to deal with this full-screen brightness issue whenever affordable TVs using that tech are actually a reality. Until then, all the QD-OLED advantages far outweigh the disadvantages, for me. I was very happy to see this Alienware monitor came factory-calibrated. All TVs and monitors should come that way. Factories should be making all their displays capable of an automated calibration routine so they can all come calibrated and we can do away with silly non-standard modes that make the picture look screwed. Manufacturers should be competing on and bragging about how accurate their pictures are, how close they get to the ideal brightness and colour depth and all that jazz. 100% of DCI-P3 is very close with a lot more displays these days. It seems the next step is to start pushing towards 100% of Rec. 2020, and that's what they should be working on and vigorously advertising how close they're getting.

Mosquitos sting now?

Cool story, but bad is bad.

It has now dawned on me, after I already submitted that reply, that you somehow misunderstood what I said and you think I meant "NVENC sucks at smaller filesizes." In fact, what I said was, given any quality level provided by NVENC, x265 will provide the same or better quality at a smaller filesize than the NVENC file. This does not mean I am using filesizes/bitrates that are too small when using NVENC. It means x265 does better with less bits than the NVENC file. Take a 50 Mbps NVENC file as a random example. 50 Mbps isn't bitstarving, is it? Then try to get similar quality from x265. It will not need to be anywhere near 50 Mbps. It will be able to do a similar job at a much lower bitrate.
  That means it is doing similar work at smaller filesizes.

Your reply doesn't even make sense. If I'm using bitrates that result in files much larger than x265 files how exactly am I bitstarving it? Disk space is cheat as dirt? Yeah, it is, which is precisely why I've got 47 TB sitting in my little file server. I'm not sitting here trying to use NVENC to get a movie to fit on a floppy. Heh.

"x265 does it better with less bits" != "I'm not using enough bitrate for NVENC"

You can use bitrates with NVENC that are far, far, FAR beyond what anyone would ever actually use with pretty stupid filesizes as a result and the quality is still blocky garbage. How about instead of saying "You don't know what you're doing." and not backing it up in any way whatsoever, you instead provide an example of settings to use for NVENC in whatever encoding software in order to show me what you consider to be good quality from NVENC? That is, if you're so sure that NVENC can actually produce good results. Surely if that's the case and you use NVENC all the time you've got some settings you typically start with because they typically produce good results, so feel free to share.

x265 and VMAF 97 look pretty good on my 75" TV in the living room. I've yet to see NVENC produce something that doesn't present artifacting clearly visible on my computer monitor, nevermind trying to watch something from it on the living room TV. The computer monitor is nowhere near the TV's size, and if artifacts are blatantly obvious on it they aren't going to be any better on the big TV. NVENC files that yield VMAF 97 results look inferior to the x265 VMAF 97 files. This comes as no surprise for two reasons. NVENC has chroma problems. And VMAF ignores chroma at the moment. Take two different VMAF 97 files, one from x265 and one from NVENC, and run it through the other common metrics and it quickly becomes obvious that the NVENC file is going to look a lot worse, without even having to view it. Viewing it only confirms what those other metrics will already have told you.

Though I do invite you to share some settings with NVENC that you feel should yield great results and I'll be happy to give it a shot and compare it to unaltered x265 presets, which I'm pretty sure will yield better results at smaller filesizes.

Metrics don't lie. I prefer VMAF, but pick whichever one you wish. The NVENC results suck. Artifacts galore, particularly in the chroma. The people looking at your encodes must be blind and/or ignorant of compression.

Surely it means that an encode that was 100 MB with HEVC is 80 MB with AV1. Also, don't confuse the goals of AV1 itself with a hardware maker's goals for their hardware. To date, all hardware encoding has sucked anyway, and I feel no optimism that this encoder will suddenly be the one that is usable.

I personally find hardware encoding useless when you don't have access to all encoding parameters. I find no gold in encoding something quickly that looks bad. This is what has bugged me about NVENC since its inception. I don't care how much work using NVENC offloads from the CPU if the video stream looks like ass. I'm not encoding for some big streaming service, or big company, or anything like that. Simply encoding my files for my own use. And all the experimenting I've done with NVENC has shown it to be a waste of silicon, at least for me. I sure wish companies spending time and money on developing hardware encoders would allow us to get results that mirror what we can get from x264 and x265, for example. Let me get results that match x264/x265 bit-for-bit and then your hardware encoder becomes useful to me. When all it delivers is vastly inferior results you've wasted all that R&D time and money, not to mention silicon. Give us encoders that can make everything from ultrafast to veryslow (hell, placebo, too) in x264/x265 possible in hardware, and similarly the entire range possible in AV1, too, and then you've got something worth talking about. And more importantly, worth using. Subpar results via hardware encoding is only useful in so many scenarios. Giving us hardware encoders that perform just as well as the software encoders is a much better goal. Yes, I'll pay more for that silicon. I want my money back on all the silicon we've got up until now, heh.