I can envision some wacky japanese game where you get to play a sexual predator. The goal of the game is to prey on women and neighbourhood children. Getting extra points for doing things like luring kids with candy or the promise of toys, and performing date rapes on unsuspecting college girls.
Dunno about children, but I'm pretty sure there
is a Japanese game where you play a
stalker/rapist and have to use stealth techniques
to sneak up on your victims. I thought I saw a
walkthrough of it at somethingawful.com several
months ago but I can't find it now.
In the meantime, Battle Raper is probably sufficient to prove
such things exist.
Yep, I noticed that as well, with Monsters Inc. and Finding Nemo. IMDB
has the DVD details for those. It shows Nemo [imdb.com] as 1.78:1 but
Monsters [imdb.com] as 1.85:1. But they both fill my 16:9 screen
perfectly.
Your display may be overscanning anyway, so even if there are thin
bars on the edges of the screen you might not see them. You'd have to
check the raw MPEG frames to be sure.
It would seem odd for Disney to chop off a tiny bit from
even the widescreen presentation.
Feh. I cannot conceive of anything being too odd for Disney to
attempt. Recall they are one of the big ones that resisted DVD in the
first place; they have a notorious release/retract cycle on certain
films; I think they were the first ones to put unskippable
advertisements at the front of DVDs; they were the first ones to try
to rig a DVD to detect a region-free player; their handling of DVD
releases of Ghibli films in both Japan and the US has had several
issues; the list goes on and on.
Now in this particular case it's computer animation. So the real
aspect ratio is whatever they rendered at. It's possible that they
actually produced at 1.78:1 and matted it to 1.85:1 for theatrical
release. Certainly many non-animated films are at least party shot at
lower ratios and matted for theaters (that's been the case for
decades).
Do theaters hold a fixed height and just pull in the
curtains to different widths depending on a 2.35, 1.85, or 1.77 aspect
ratio?
Depends on the projection equipment/lenses, I think. I'm pretty
sure I've seen it done both ways. Most films are probably
projected at either 1.85:1 or 2.35:1 regardless of their production ratio.
During the last movie I saw (LOTR:ROTK) I tried to imagine what
it would look like if you had to chop off 76% of the width to fit it
to a 4:3 TV. You lose a ridiculous amount of screen area.
IMDB claims ROTK was shot in Super35, which I think typically
means that it's physically filmed at 4:3 and masked for theatrical
presentation. So the full-frame transfer can actually open up the
frame vertically and reveal more picture information to reduce the
amount of pan/scan. Now IMDB also claims that they used some ARRI 2.35
research lens, and I see that ARRI has a 3-perf Super35 conversion (to
save film) that changes the native ratio to 16:9 instead of 4:3. So
they might have done something like that. Or maybe that research lens
is actually some anamorphic lens that results in an even higher native
ratio. All that being said, the effects shots are probably rendered at
no less than 16:9, so in those parts of the film the full screen
transfer almost certainly requires quite a bit of pan and scan.
(1) Why do we still have so many different
display-formatted DVDs out there (full-screen and wide-screen)? How
difficult would it have been to simply make every DVD the same, and to
supply a set of panning instructions to the DVD player itself to
specify what visual portion of the movie will be displayed in
full-screen mode?
It's more complicated than that. A full-frame transfer of a film
is not always just a simple crop/zoom of the widescreen version. For
example the Super35 film process (among others) actually shoots at a
lower aspect ratio and is masked for theater presentation. If the DP
takes that into account when framing the shots, the full-frame
transfer can actually unmask some of this (revealing content above and
below the wide-screen frame) to help fill out the image and reduce
the amount of cropping and panning required. But then some
effects shots in the same film might use a different film process or
be rendered/digitally processed at a ratio that doesn't match the
rest of the footage, so in those particular sections the cropping/zooming
is again handled differently. I suspect each film is a bit different.
2) Going off the same idea as #1, why couldn't these
DVDs have been set up to be HDTV compatible in the first place? I
realize that HDTV has a higher resolution and whatnot, but... how hard
would it have been to force DVDs to meet the HDTV standard and simply
resize the visuals for non-HDTV televisions?
I think you underestimate the amount of processing required for
HD. This would require the player to incorporate an MPEG decoder and
video scaler capable of handling HDTV resolutions and bitrates. The
cheapest devices I know of today that can do that are about
$500, and that doesn't include any sort of media drive (you have to
feed the data to them over something like Ethernet or 8VSB).
I wasn't too happy to know that I'd have to go buy a brand-new $300 player just
to play dual-layer DVDs.
You did? Must have been a very early adopter, I guess.
(4) Also, why aren't all DVDs compatible with all the
different DVD players out there? If DVD is a standardized format and
all,
I believe it is.
why am I still finding a movie every once in a while that works in
one player but not the other?
Because the folks producing DVDs don't make them properly. Read
the development lists for software DVD players (xine, Mplayer, ogle)
for a while and you'll hear mention of all sorts of misproduced
and buggy DVDs.
And then you have companies intentionally playing shenanigans like
having the DVD try to detect if a player has been region-unlocked; or
trying to feed you advertising while blocking the ability to skip over
them. That stuff doesn't make the situation any better.
And then there's the firmware in the players, which might also
have obscure bugs that only certain DVDs trigger.
(5) Now... this last one is just kinda nit-picky, but... regarding at
least half of the DVDs I own, I absolutely hate their menus. Half the
time I can't even tell what I'm selecting on the screen, or even know
what all my options are. I know being unique is good and all, but why
should a DVD that I purchased with my own money feel so alienated to
me? Why must I solve puzzles to go through everything contained on my
DVD?
Why do some folks produce websites that only function if you have
the latest Flash and/or JavaScript support? Why do some folks use
Word, Excel, or PowerPoint when simple text would suffice? Because
some designers will happily sacrifice usability to make something
"look cool", and that problem isn't ever going to go away. The same
situation has existed in the application CDROM world since day zero.
Hell, even Apple throws their own GUI style guide out the
window when it comes to doing multimedia applications.
Well it never made it to US shelves; just Japan
and Europe.
Mojibu Ribbon, which I think
is a sequel of sorts, was just released in Japan
last month. But I've read that the new game uses text
rather than music so I don't know if it's even playable
without being able to read and write Japanese.
Any remotely modern monitor will then report its optimal refresh rates to the video card when X starts.
Except that sometimes the data from the monitor
is not reliable or complete. My Samsung 19" tube
tells the computer that it can only go
up to 1600x1200, but if you take the frequency
ranges from the manual, you find that it can
actually sync 1920x1440. So to get the desired
higher resolution I have to either put a KVM
switch in the loop that blocks EDID, or
explain to the driver that the monitor is a liar.
No more modeline yuckiness.:-)
Even with DDC/EDID turned off, I don't think I've had to deal with
a modeline directly since XFree86 3.x. Recent
servers have a bunch of "standard" modelines
built into them. The only time I recall working
with a modeline in the last few years was when I
was using some specific oddball timings and
external signal conversion hardware to trick
a projector that doesn't usually work
with computer video at all.
I believe the rules for the world record say that you must play on Heavy mode.
Whose rules?
Supposedly the rules Guiness gave him
were not really DDR-specific but were
based on their standard endurance event
rules. There were no rules regarding
things like skill level or bar usage.
I actually plan on trying to break the record
myself, though I wonder if I have the sanity
to do so.
The player, or at least someone purporting to
be him, has warned over on ddrfreak that by
doing this he's found that DDR is no longer fun
for him at all.
He's recommending that anyone else considering
this sort of record should think about whether
they want to risk losing all enjoyment of the
game.
That my friend is what ground loop isolators are for. If you have a ground loop problem (and you'll know it if you do) you pop one of these simple little devices onto the problem connection... and problem solved.
Yep, been there, done that. When I hooked both my cable and OTA antenna lines into the system, which are grounded together outside the house, I got a noticable hum out of my mains amp. Currently I use homebrew isolaters on both lines made from baluns wired back-to-back, which solved that problem (I had to make sure to get the type that don't have a sneaky little ground wire across the transformer:-)
The problem with the isolator approach is finding
the source of the loop, getting the right type of isolator, and isolating enough of the lines to kill it dead. Which is why I still prefer optical, since it completely eliminates that connection as a possibility. Plus there's the whole issue with it preventing an electrical spike from using that connection, though I know there's a zillion other interconnections I'm not going to be able to isolate.
Of course you could also solve it with a well wired home.
Don't even get me started on that situation. I
do intend to put in several new runs to the
equipment, so that I can spread the load out a bit and contemplate things like kilowatt amps (e.g. for Buttkicker devices).
Ground loop problems aren't as common as the guys at Best Buy would have you believe.
I know better than to believe anything that comes out of the mouth of a BB salesman. Granted some of them might know what they're talking about, but I want better odds before I'll place that bet.
Not to mention that the more connections (ie electron to light and light to electron convertor circuits) the more potential to introduce errors.
Yes, but the more electrical connections
you have, the more potential to introduce ground
loops and hum into the entire system. I usually prefer optical over coax because
it keeps things electrically isolated. Especially
if I have the equipment spread out over
multiple circuits.
I wonder if it's processor is even powerful enough to decode a 1080i digital stream...?
The CPU is an ATI Xilleon, which ATI claims can
decode two HDTV streams simultaneously (it has integrated hardware MPEG decoding). The Roku engineers have put transport stream decoding into the latest beta firmware, but I haven't done any stress testing of it yet. There is certainly a lot of interest in using the device as a playback engine for HDTV captures.
First, does the HD1000 support IR based remotes out of the box
The stock Roku remote is an IR unit. I don't
know how programmable things are on the Roku
itself, for example if you can get the unit
to understand additional codes.
is the software interface designed to be used while looking at a standard television from a respectable distance?
Certainly from an HDTV, which would tend to have
a large screen. I don't know about a "standard"
TV. They have some screen shots of the current interface on their web site, so you might consider what those would be like on your TV. It may be that you'll be able to customize this further (larger fonts or whatever) when the SDK comes out.
I too have a pcHDTV card. And I have yet to
find a computer that could play back those
transport streams at full resolution completely
smoothly. The strongest machine I've
tried so far was an Athlon XP 2400+ with
GeForce FX 5200, Nvidia drivers, and Xine with
XvMC support -- and it was not up to the job.
The Roku has HDTV decompression hardware
in it, and certainly costs less than any
machine for this job that I could build myself.
It's also small and fanless.
I plan on doing some stress tests in a few
days to
see how well the latest Roku firmware
handles my pcHDTV streams.
and hi-def disks (in any format, unless someone comes out with one on a laser-disc size platter)
Actually Japanese Hi-Vision (HD) Laserdiscs
have been available for years. But they're
very expensive, and it's an analog HD
format rather than digital.
And I'm sure that as with normal Laserdiscs,
they're heavy enough to crush any shelf you
try to store them on:-)
I've got a pcHDTV card and have done some
transport stream captures in Linux. I've
tried playing them back on a friend's
Shuttle XPC (running Linux) with an
Athlon XP2400+ and GeForceFX 5200.
NVidia's drivers do support XvMC (motion
compensation) on this card, and Xine is able to
take advantage of it. But I'm still not 100%
thrilled with the performance. There's some
slight judder/jitter, mostly noticable in smooth
pans, and that's with everything scaled to 1280
pixels wide. If I try to run the display at
1920 pixels wide, it seems to stress the fill
rate or in any case cause it to get much
choppier.
Supposedly GeForce4 MX cards might actually
have better XvMC support, but I haven't
verified this. For this specific purpose I
think the general advice is that the GF4MX
cards are better than GF4Ti models.
Not that Windows HD cards and drivers are
apparently much better. I've seen complaints
from at least one Windows HTPC user that
he's not happy with playback there either.
So a bunch of us are watching the
Roku HD1000
unit very closely. This is a set-top
box based around the ATI Xilleon chip -- a MIPS
core surrounded by specialized graphics hardware,
including full HDTV MPEG decoding.
Best of all,
it runs Linux. An initial SDK (gcc toolchain)
is due out in the next week or so. There are
Roku folks hanging out in the
main Roku thread at avsforum, and have been
answering questions and taking suggestions. They
also just set up a
mailing list of their own
for technical discussions.
As soon
as the product was announced there were a bunch
of us who immediately thought of using this
as a transport stream player, and although
the initial firmware does not do that, they
have already released two beta versions in the
last few weeks developing this as a feature.
Apparently their developers
also have HD capture cards and have an interest
in making this work:-)
You probably also have a giagantic screen, yes? 1280x1020 or above?
I normally run my home systems at 1920x1440, and I'd go even higher if my monitors would sync it.
Doesn't sound like you have many windows open either.
Maybe a dozen Galeon windows, 2-8 emacs windows, a couple Netscape 4 windows for certain things, xterms all over the place, gimp occasionally, and so on. Heck, I've had up to 35 torrents going at once along with the rest of that.
I do use virtual desktops to sort all this out. Each desktop is usually task-based. So for example on the first one I might have all of my "regular" web browsing; on the second I'm dealing with email; the third is where I'm building application xyz; the fourth is where I'm boostrapping a new glibc toolchain; the fifth is where I'm looking at kernel source; the sixth is where I'm downloading videogame trailers, and so on. In many cases I'll have virtual desktops where all of the windows are remote-displayed from some other machine, or where they're all running as some special-purpose user (e.g. I might have a special "xyz" account for building application xyz).
I sure as hell couldn't have all of this going on one desktop. I've used MacOS (9, admittedly) on a dual 1600x1200 system, and I know firsthand what a crappy environment that was.
I'd like to see you manage 40 open windows and find ONE quickly, please. Oh, what's the matter, your scheme doesn't work for more than 3-4 windows per virtual terminal?
Personally I do like the idea of using Expose on each desktop. Provided I can still spread everything out over multiple desktops. If I had to put 20 xterms on the same desktop and then use Expose, I'm not sure it would help since by the time they were all small enough to be tiled I wouldn't be able to tell them apart.:-)
The Register had a story about a year ago about Microsoft teaming with a place like Samsung to develop a large LCD screen that had a ridiculously high resolution. Something along the lines of 5,000 pixels wide.
I don't know about Samsung, but IBM and Viewsonic at least have had 3840x2400 LCDs available for a while now.
VERY excited about that.;)
If prices for the existingmodels are any indication, your bank account may be more terrified than excited:-). And that probably doesn't even include the graphics card(s) needed to run these beasts.
Apparently the third home version just came out a few days ago (will be placing my order as soon as I finish posting this:-), and a fourth is expected in December.
Maybe that's why it hasn't been released here, Americans would rather play killing games than play dance/music games I guess.
Well, there's some other issues with Taiko no Tatsujin that make it less likely to ever show up in the US:
Special controller.
Music-based, which means licensing and rights issues. DDR has certainly had this problem.
Heavy use of Japanese in the interface, including vertical text. Localization could be a bit of work.
Nutty graphics/character design, though I suppose that didn't stop Gitaroo-Man.
Essentially no arcade presence. Again, DDR is at an advantage here because even the unlicensed JP machines are almost entirely in English.
...with RS-232, Ethernet, flashable firmware, a forthcoming SDK, and HDTV-ready MPEG decoding hardware. Oh, and fits in a fanless set-top box.
Now, the first thing that came to mind for me, when I found out about this, is that it looks to be an almost ideal customizable outboard MPEG decoder for watching captured/recorded HDTV -- for less money than anything I could build myself. Apparently I wasn't alone, because after I sent my questions to the company about streaming compressed HDTV to the box, I checked over at avsforum.com and found lots other people were asking the same questions.
Capturing HDTV off the air is relatively easy. It can even be done on an old Linux machine with a pchdtv.com card. Smooth full-resolution playback, however, is a bitch.
Unfortunately the initial Roku firmware is aimed mainly at supporting the art packs, and while it does apparently have some HDTV playback capability it's (at least with the first release) very finicky about the content of the transport stream. At least one person from the company has shown up in the AVS forums and is answering questions there, which is nice. I think many of us are just waiting for somebody to get their hands on one of these and see what it can do -- or can be made to do;-)
Recording is easy, since you usually record the highly-compressed transport stream right off the air and don't bother with any MPEG decompression. As mentioned it's about 19Mbit/sec for over-the-air stations, so figure 8-10Gbyte/hour.
I think on CATV it can run at 38Mbit/sec, but I don't know if there are any cable providers actually doing that, or cards that can capture it.
Now, bear in mind that 19Mbit is the entire channel, and broadcasters sometimes multiplex multiple programs into a single channel. For example the local PBS station runs four standard definition subchannels during the day, then at prime time switches to one SD and one HD. So if you know which subchannel(s) you really want, you could in theory filter the transport stream before storing it (and therefore use less disk space by not storing "Barney" while recording "Nova"). This sort of filtering again requires no MPEG decompression, and should be possible without much CPU power.
I've been doing captures without difficulty on a K7-800 to a 7200RPM Firewire drive, while doing other things on the machine.
Playback however is an entirely different matter. For that I've been using an XP2400 with GeForceFX 5200 and it's still not completely smooth. Newer Nvidia drivers, or a card with better XvMC support (GeForce4 MX is supposedly very good), might help that.
Moving the compressed transport stream around is easy. Actually decompressing it to a viewable image is a huge workload. There's a new set-top box called the Roku which supposedly has full HDTV hardware decompression, a network port, and runs Linux internally. Several people have asked the company about the ability to use it as an outboard MPEG player, but apparently the initial software isn't designed to do that (or at least to make it easy:-)
In order to use GPL'd source you have to agree to the GPL's terms.
Obligatory response: it depends on what you want to do with the source. Typical use, such as running a GPL'd program, does not normally
require acceptance of the GPL. From GPLv2
section 5:
You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License.
Those 170x monitors were actually very durable, they were made by JVC, I believe.
Yup, I've got a 1702 myself and it still works like a champ whenever I need an NTSC-compatible display. Just recently I had it attached to a PS2 for about a year (using S-Video and a breakout adapter to connect to the Y/C ports on the back), and used it several hours a week.
This sort of technique is definitely still in
use. About two years ago there was a lengthy
article on Gamasutra (since
moved to the members-only area) from
the folks that implemented the copy protection in "Spyro: Year of The Dragon".
Developers know that a
game will be cracked soon after it comes out,
sometimes within a few days;
but also that most of the sales are going to occur
right after release as well. So the goal is to hold off and
confuse the crackers for at least long enough
to get past the sales peak. Among the (many) strategies
they used was that if a crack was detected, it
wouldn't have any noticable effect until a few
levels later. For example one of the pickups
you'd need to complete a level might not be
there. Delaying the effect made it harder for
someone cracking the game to figure out when and
where in the code the detection occurred.
With the ever-increasing clock speed of our CPUs, what is the point
of having a hardware MPEG decoder? I understand that p2-400 is sufficient
to play DVD-quality movies.
But is "DVD-quality" enough?
I just spent the better part of an evening working with some HDTV
1080i streams, and the Athlon XP 2400+ in the test playback machine
does not appear to be fast enough to do the MPEG decoding entirely in
software.
The machine does have a GeForceFX 5200 in it. With the latest
NVidia drivers and a xine with XvMC support, it's able to offload some
of the decoding work onto the card, which definitely
helps. But even then it still doesn't seem to be powerful enough to
deinterlace and fill a full 1920x1080 pixels. Scaling the display down
to 1280 pixels wide makes it run smoother; a better card might help as
well.
You also have to consider what a given viewer thinks is
"sufficient". For me, if the computer cannot do the decoding at
least as smoothly and cleanly as a 2-year-old
dedicated set-top-box, then
it still needs some work.
For instance, if I am Adobe looking to port Premiere to Linux, which toolkit should I use? Qt/KDE? GTK/Gnome?
And one need only look at some of the older attempts to see how bad things can be if the wrong choices are made.
Speaking of Adobe, the old Unix versions of Photoshop come immediately to mind. For example the file chooser was this horrible monstrosity that tried to pretend the system was a Mac and made no sense at all to a normal Unix user.
It also interacted very badly with anything other than the stock vendor window manager; I can recall things like manually resizing or moving a window (I think I was using ctwm at the time), only to have Photoshop shortly
thereafter change the size or position of the window to something else on its own. Bizarre, and very, very annoying if nothing else.
And then there's the Solaris version of Internet Explorer, which basically seemed to be a conversion of every Windows DLL over to a Solaris shared library, all loaded and occupying some ghastly amount of memory and looking/acting exactly like the Windows GUI. At least that's what I recall of the beta versions. I think they also had a "Motif" display option, but that it worked worse.
Slashdot Mirror
Dunno about children, but I'm pretty sure there is a Japanese game where you play a stalker/rapist and have to use stealth techniques to sneak up on your victims. I thought I saw a walkthrough of it at somethingawful.com several months ago but I can't find it now.
In the meantime, Battle Raper is probably sufficient to prove such things exist.
Your display may be overscanning anyway, so even if there are thin bars on the edges of the screen you might not see them. You'd have to check the raw MPEG frames to be sure.
Feh. I cannot conceive of anything being too odd for Disney to attempt. Recall they are one of the big ones that resisted DVD in the first place; they have a notorious release/retract cycle on certain films; I think they were the first ones to put unskippable advertisements at the front of DVDs; they were the first ones to try to rig a DVD to detect a region-free player; their handling of DVD releases of Ghibli films in both Japan and the US has had several issues; the list goes on and on.
Now in this particular case it's computer animation. So the real aspect ratio is whatever they rendered at. It's possible that they actually produced at 1.78:1 and matted it to 1.85:1 for theatrical release. Certainly many non-animated films are at least party shot at lower ratios and matted for theaters (that's been the case for decades).
Depends on the projection equipment/lenses, I think. I'm pretty sure I've seen it done both ways. Most films are probably projected at either 1.85:1 or 2.35:1 regardless of their production ratio.
IMDB claims ROTK was shot in Super35, which I think typically means that it's physically filmed at 4:3 and masked for theatrical presentation. So the full-frame transfer can actually open up the frame vertically and reveal more picture information to reduce the amount of pan/scan. Now IMDB also claims that they used some ARRI 2.35 research lens, and I see that ARRI has a 3-perf Super35 conversion (to save film) that changes the native ratio to 16:9 instead of 4:3. So they might have done something like that. Or maybe that research lens is actually some anamorphic lens that results in an even higher native ratio. All that being said, the effects shots are probably rendered at no less than 16:9, so in those parts of the film the full screen transfer almost certainly requires quite a bit of pan and scan.
It's more complicated than that. A full-frame transfer of a film is not always just a simple crop/zoom of the widescreen version. For example the Super35 film process (among others) actually shoots at a lower aspect ratio and is masked for theater presentation. If the DP takes that into account when framing the shots, the full-frame transfer can actually unmask some of this (revealing content above and below the wide-screen frame) to help fill out the image and reduce the amount of cropping and panning required. But then some effects shots in the same film might use a different film process or be rendered/digitally processed at a ratio that doesn't match the rest of the footage, so in those particular sections the cropping/zooming is again handled differently. I suspect each film is a bit different.
I think you underestimate the amount of processing required for HD. This would require the player to incorporate an MPEG decoder and video scaler capable of handling HDTV resolutions and bitrates. The cheapest devices I know of today that can do that are about $500, and that doesn't include any sort of media drive (you have to feed the data to them over something like Ethernet or 8VSB).
You did? Must have been a very early adopter, I guess.
I believe it is.
Because the folks producing DVDs don't make them properly. Read the development lists for software DVD players (xine, Mplayer, ogle) for a while and you'll hear mention of all sorts of misproduced and buggy DVDs.
And then you have companies intentionally playing shenanigans like having the DVD try to detect if a player has been region-unlocked; or trying to feed you advertising while blocking the ability to skip over them. That stuff doesn't make the situation any better.
And then there's the firmware in the players, which might also have obscure bugs that only certain DVDs trigger.
Why do some folks produce websites that only function if you have the latest Flash and/or JavaScript support? Why do some folks use Word, Excel, or PowerPoint when simple text would suffice? Because some designers will happily sacrifice usability to make something "look cool", and that problem isn't ever going to go away. The same situation has existed in the application CDROM world since day zero. Hell, even Apple throws their own GUI style guide out the window when it comes to doing multimedia applications.
Well it never made it to US shelves; just Japan and Europe.
Mojibu Ribbon, which I think is a sequel of sorts, was just released in Japan last month. But I've read that the new game uses text rather than music so I don't know if it's even playable without being able to read and write Japanese.
Except that sometimes the data from the monitor is not reliable or complete. My Samsung 19" tube tells the computer that it can only go up to 1600x1200, but if you take the frequency ranges from the manual, you find that it can actually sync 1920x1440. So to get the desired higher resolution I have to either put a KVM switch in the loop that blocks EDID, or explain to the driver that the monitor is a liar.
Even with DDC/EDID turned off, I don't think I've had to deal with a modeline directly since XFree86 3.x. Recent servers have a bunch of "standard" modelines built into them. The only time I recall working with a modeline in the last few years was when I was using some specific oddball timings and external signal conversion hardware to trick a projector that doesn't usually work with computer video at all.
Whose rules? Supposedly the rules Guiness gave him were not really DDR-specific but were based on their standard endurance event rules. There were no rules regarding things like skill level or bar usage.
The player, or at least someone purporting to be him, has warned over on ddrfreak that by doing this he's found that DDR is no longer fun for him at all. He's recommending that anyone else considering this sort of record should think about whether they want to risk losing all enjoyment of the game.
Yep, been there, done that. When I hooked both my cable and OTA antenna lines into the system, which are grounded together outside the house, I got a noticable hum out of my mains amp. Currently I use homebrew isolaters on both lines made from baluns wired back-to-back, which solved that problem (I had to make sure to get the type that don't have a sneaky little ground wire across the transformer :-)
The problem with the isolator approach is finding the source of the loop, getting the right type of isolator, and isolating enough of the lines to kill it dead. Which is why I still prefer optical, since it completely eliminates that connection as a possibility. Plus there's the whole issue with it preventing an electrical spike from using that connection, though I know there's a zillion other interconnections I'm not going to be able to isolate.
Don't even get me started on that situation. I do intend to put in several new runs to the equipment, so that I can spread the load out a bit and contemplate things like kilowatt amps (e.g. for Buttkicker devices).
I know better than to believe anything that comes out of the mouth of a BB salesman. Granted some of them might know what they're talking about, but I want better odds before I'll place that bet.
Yes, but the more electrical connections you have, the more potential to introduce ground loops and hum into the entire system. I usually prefer optical over coax because it keeps things electrically isolated. Especially if I have the equipment spread out over multiple circuits.
The CPU is an ATI Xilleon, which ATI claims can decode two HDTV streams simultaneously (it has integrated hardware MPEG decoding). The Roku engineers have put transport stream decoding into the latest beta firmware, but I haven't done any stress testing of it yet. There is certainly a lot of interest in using the device as a playback engine for HDTV captures.
The stock Roku remote is an IR unit. I don't know how programmable things are on the Roku itself, for example if you can get the unit to understand additional codes.
Certainly from an HDTV, which would tend to have a large screen. I don't know about a "standard" TV. They have some screen shots of the current interface on their web site, so you might consider what those would be like on your TV. It may be that you'll be able to customize this further (larger fonts or whatever) when the SDK comes out.
I too have a pcHDTV card. And I have yet to find a computer that could play back those transport streams at full resolution completely smoothly. The strongest machine I've tried so far was an Athlon XP 2400+ with GeForce FX 5200, Nvidia drivers, and Xine with XvMC support -- and it was not up to the job.
The Roku has HDTV decompression hardware in it, and certainly costs less than any machine for this job that I could build myself. It's also small and fanless. I plan on doing some stress tests in a few days to see how well the latest Roku firmware handles my pcHDTV streams.
Actually Japanese Hi-Vision (HD) Laserdiscs have been available for years. But they're very expensive, and it's an analog HD format rather than digital.
And I'm sure that as with normal Laserdiscs, they're heavy enough to crush any shelf you try to store them on :-)
I've got a pcHDTV card and have done some transport stream captures in Linux. I've tried playing them back on a friend's Shuttle XPC (running Linux) with an Athlon XP2400+ and GeForceFX 5200. NVidia's drivers do support XvMC (motion compensation) on this card, and Xine is able to take advantage of it. But I'm still not 100% thrilled with the performance. There's some slight judder/jitter, mostly noticable in smooth pans, and that's with everything scaled to 1280 pixels wide. If I try to run the display at 1920 pixels wide, it seems to stress the fill rate or in any case cause it to get much choppier.
Supposedly GeForce4 MX cards might actually have better XvMC support, but I haven't verified this. For this specific purpose I think the general advice is that the GF4MX cards are better than GF4Ti models.
Not that Windows HD cards and drivers are apparently much better. I've seen complaints from at least one Windows HTPC user that he's not happy with playback there either.
So a bunch of us are watching the Roku HD1000 unit very closely. This is a set-top box based around the ATI Xilleon chip -- a MIPS core surrounded by specialized graphics hardware, including full HDTV MPEG decoding.
Best of all, it runs Linux. An initial SDK (gcc toolchain) is due out in the next week or so. There are Roku folks hanging out in the main Roku thread at avsforum, and have been answering questions and taking suggestions. They also just set up a mailing list of their own for technical discussions.
As soon as the product was announced there were a bunch of us who immediately thought of using this as a transport stream player, and although the initial firmware does not do that, they have already released two beta versions in the last few weeks developing this as a feature. Apparently their developers also have HD capture cards and have an interest in making this work :-)
I normally run my home systems at 1920x1440, and I'd go even higher if my monitors would sync it.
Maybe a dozen Galeon windows, 2-8 emacs windows, a couple Netscape 4 windows for certain things, xterms all over the place, gimp occasionally, and so on. Heck, I've had up to 35 torrents going at once along with the rest of that.
I do use virtual desktops to sort all this out. Each desktop is usually task-based. So for example on the first one I might have all of my "regular" web browsing; on the second I'm dealing with email; the third is where I'm building application xyz; the fourth is where I'm boostrapping a new glibc toolchain; the fifth is where I'm looking at kernel source; the sixth is where I'm downloading videogame trailers, and so on. In many cases I'll have virtual desktops where all of the windows are remote-displayed from some other machine, or where they're all running as some special-purpose user (e.g. I might have a special "xyz" account for building application xyz).
I sure as hell couldn't have all of this going on one desktop. I've used MacOS (9, admittedly) on a dual 1600x1200 system, and I know firsthand what a crappy environment that was.
Personally I do like the idea of using Expose on each desktop. Provided I can still spread everything out over multiple desktops. If I had to put 20 xterms on the same desktop and then use Expose, I'm not sure it would help since by the time they were all small enough to be tiled I wouldn't be able to tell them apart. :-)
I don't know about Samsung, but IBM and Viewsonic at least have had 3840x2400 LCDs available for a while now.
If prices for the existing models are any indication, your bank account may be more terrified than excited :-). And that probably doesn't even include the graphics card(s) needed to run these beasts.
Apparently the third home version just came out a few days ago (will be placing my order as soon as I finish posting this :-), and a fourth is expected in December.
Well, there's some other issues with Taiko no Tatsujin that make it less likely to ever show up in the US:
Apparently GTA3 was released in Japan in September and was still in the top ten software sales last week.
http://general.gamerfeed.com/gf/news/4609/http://www.m-create.com/eng/e_ranking.html
The Roku box is a Linux computer...
Now, the first thing that came to mind for me, when I found out about this, is that it looks to be an almost ideal customizable outboard MPEG decoder for watching captured/recorded HDTV -- for less money than anything I could build myself. Apparently I wasn't alone, because after I sent my questions to the company about streaming compressed HDTV to the box, I checked over at avsforum.com and found lots other people were asking the same questions.
Capturing HDTV off the air is relatively easy. It can even be done on an old Linux machine with a pchdtv.com card. Smooth full-resolution playback, however, is a bitch.
Unfortunately the initial Roku firmware is aimed mainly at supporting the art packs, and while it does apparently have some HDTV playback capability it's (at least with the first release) very finicky about the content of the transport stream. At least one person from the company has shown up in the AVS forums and is answering questions there, which is nice. I think many of us are just waiting for somebody to get their hands on one of these and see what it can do -- or can be made to do ;-)
Recording is easy, since you usually record the highly-compressed transport stream right off the air and don't bother with any MPEG decompression. As mentioned it's about 19Mbit/sec for over-the-air stations, so figure 8-10Gbyte/hour.
:-)
I think on CATV it can run at 38Mbit/sec, but I don't know if there are any cable providers actually doing that, or cards that can capture it.
Now, bear in mind that 19Mbit is the entire channel, and broadcasters sometimes multiplex multiple programs into a single channel. For example the local PBS station runs four standard definition subchannels during the day, then at prime time switches to one SD and one HD. So if you know which subchannel(s) you really want, you could in theory filter the transport stream before storing it (and therefore use less disk space by not storing "Barney" while recording "Nova"). This sort of filtering again requires no MPEG decompression, and should be possible without much CPU power.
I've been doing captures without difficulty on a K7-800 to a 7200RPM Firewire drive, while doing other things on the machine.
Playback however is an entirely different matter. For that I've been using an XP2400 with GeForceFX 5200 and it's still not completely smooth. Newer Nvidia drivers, or a card with better XvMC support (GeForce4 MX is supposedly very good), might help that.
Moving the compressed transport stream around is easy. Actually decompressing it to a viewable image is a huge workload. There's a new set-top box called the Roku which supposedly has full HDTV hardware decompression, a network port, and runs Linux internally. Several people have asked the company about the ability to use it as an outboard MPEG player, but apparently the initial software isn't designed to do that (or at least to make it easy
Obligatory response: it depends on what you want to do with the source. Typical use, such as running a GPL'd program, does not normally require acceptance of the GPL. From GPLv2 section 5:
Or about 60 compressed HDTV movies.
Or maybe one uncompressed HDTV movie. But it'll have to be a short one :-)
Yup, I've got a 1702 myself and it still works like a champ whenever I need an NTSC-compatible display. Just recently I had it attached to a PS2 for about a year (using S-Video and a breakout adapter to connect to the Y/C ports on the back), and used it several hours a week.
This sort of technique is definitely still in use. About two years ago there was a lengthy article on Gamasutra (since moved to the members-only area) from the folks that implemented the copy protection in "Spyro: Year of The Dragon".
Developers know that a game will be cracked soon after it comes out, sometimes within a few days; but also that most of the sales are going to occur right after release as well. So the goal is to hold off and confuse the crackers for at least long enough to get past the sales peak. Among the (many) strategies they used was that if a crack was detected, it wouldn't have any noticable effect until a few levels later. For example one of the pickups you'd need to complete a level might not be there. Delaying the effect made it harder for someone cracking the game to figure out when and where in the code the detection occurred.
But is "DVD-quality" enough?
I just spent the better part of an evening working with some HDTV 1080i streams, and the Athlon XP 2400+ in the test playback machine does not appear to be fast enough to do the MPEG decoding entirely in software.
The machine does have a GeForceFX 5200 in it. With the latest NVidia drivers and a xine with XvMC support, it's able to offload some of the decoding work onto the card, which definitely helps. But even then it still doesn't seem to be powerful enough to deinterlace and fill a full 1920x1080 pixels. Scaling the display down to 1280 pixels wide makes it run smoother; a better card might help as well.
You also have to consider what a given viewer thinks is "sufficient". For me, if the computer cannot do the decoding at least as smoothly and cleanly as a 2-year-old dedicated set-top-box, then it still needs some work.
And one need only look at some of the older attempts to see how bad things can be if the wrong choices are made.
Speaking of Adobe, the old Unix versions of Photoshop come immediately to mind. For example the file chooser was this horrible monstrosity that tried to pretend the system was a Mac and made no sense at all to a normal Unix user. It also interacted very badly with anything other than the stock vendor window manager; I can recall things like manually resizing or moving a window (I think I was using ctwm at the time), only to have Photoshop shortly thereafter change the size or position of the window to something else on its own. Bizarre, and very, very annoying if nothing else.
And then there's the Solaris version of Internet Explorer, which basically seemed to be a conversion of every Windows DLL over to a Solaris shared library, all loaded and occupying some ghastly amount of memory and looking/acting exactly like the Windows GUI. At least that's what I recall of the beta versions. I think they also had a "Motif" display option, but that it worked worse.