4/01/2021

What if we're Pinball Machines not Memory Machines?

 Thinking about thought.

We tend to categorize by like is like, associations.

So we think of our brain and our thoughts like a computer programming running on a central processor.

Its something we sort of intuitively understand, and is sort of like the machines we hold in our hands. Turn crank, procedural kinetic motion produces output.

Memory is a little more like referring to a pen and paper and referring to a book for past mechanical motions.. the results.. become memory.

And we think our memory is like a book, the end result of our past mechanical actions.

But what if its more like a result machine, not that it methodically copies and encodes inputs like writing on a strip of paper.. but more like a spikey soccer ball with lots and lots of spikes.. that the envionment twists and turns and tumbles and leaves it laying in a pseudorandom state.

Not in a methodical easy to copy and recompose manner.. but the end result of a wad of paper crumpled and torn, and shaped by endless unpredictable blows and interactions with its environment.

More like a 'pinball' in a pinball machine.. its not as much a copier of the inputs from the environment.. as it is a reactor machine that seeks merely survive to experience another day.. an endless purgatory machine endlessly suffering.. the best outcome is not to cease functioning.

To extract memories.. or something more portable to easy to download and upload then.

Might be much harder.

We might rather need to  subject this tumbling soccer ball to a virtual environment to observe how its current state 'reacts' to all of its past experiences and currently interprets that which we erroneously perceive as the 'past' at the present time.

In such a scenario then, the 'past' or 'memory' becomes an endless sense of partially true, but also partially self described recollections of what its been through.. its not so much what it remembers.. as it is how it dictates or understands as its current view of the past. So.. in order to 'recall' the past.. it must forma virtual environment.. a virtual machine inside its head.. and use its imaginary narrative pointer and point it at this virtual machine in order to play out scenarios.. sort of 'imagine its 10 years ago and I'm walking through my house.. what do I see?' Then the current brain or mind 'state' begins reacting to the virtual environment and feeding senses of sight, hearing, smell into its current inputs via virtual imaginary sensors and playing out the Theater as if it were a play.. and holding those experiences  in something akin to a temporary memory buffer in our heads.. much more akin to a linear computer memory buffer.. so we can use those experiences as a near term second set of senses that can act as a mini-brain in a virtual environment to model a scenario we are trying to solve for.. to predict a near term desirable outcome.. sort of a Monte Carlo situation where we try try again in our tiny version of minecraft to come up with a solution we think will be worth betting on an the real world with our bodies.

If true.. if you want to tap into that.

It might be to extract or copy a memory.. or make new ones by uploading.. you need to tap into the virtual machine used for near term temporary memory.. and the senses it uses for input and output.. be they real or imaginary.

The real senses.. using head gear and tactile feedback like mice our keyboards.. we kind of have a grasp upon.

The temporary virtual machine senses of near term memory, we kind of don't have a good grasp of.

Magnetic Induction, neuralink.. are pokes in that direction.. but until we have a more solid connection to the temporary memory virtual machine and can spawn a set of neuralink virtual senses which the brain will accept as 'like' those it creates on the fly for visualizing scenarios for solving problems.. it could be a tough road.

Video games and game console controllers are close, they can immerse a person in a world without physical contact.. even trigger an imaginary experience where we use our perceived memory of reaction based on our past experiences. In such a situation the first person shooter is literally building their own bridge to the outside world and reacting based on their memories.. downloading  in that scenario is akin to interrogating a player for what they recall.. in real time.. since their arms and legs.. can only move in real time.

But we know we can think much faster than physical action.. the effective bandwidth can be increased in a dream state.. abbreviating or hopscotching across a dreamscape to lessor or more important elements of the story.

And in fact we know we can Upload memories very easily.. by watching a movie. Again the brain finds a way to bridge the gap.

Given the way the brain uses glucose and oxygen.. it may be that a person can only upload and download at faster than real time in a subdued, physically inactive dream state.. in which they are paralyzed to optimize nutrients and oxygen and blood supply for the brain.



3/02/2021

Startech USB2TVTuner is based on EMPia Audio and EMPia Video chips Not WIS GO007

 

So it turned out the Startech USB2TVTuner is not a hardware compression based device. Hailing from the year 2002 and sold up thru 2007 it was basically a simple YUV digitizer with USB bridge to get the raw 4:2:2 from the capture chips to the software on a PC.

I found this out after examining a unit that no longer worked.. the hardware was busted in some manner. 

And confirmed looking into a device driver .INF file which only referenced EMPia capture chip technology.

This leaves the ADS DX2 Express and the Pinnacle dazzle AVC-130 and AVC-170 as the most common WIS GO007 hardware capture devices. But only the ADS DX2 had a not ready for prime time 64 bit device driver that was never signed and roughly works under Windows 7 x64 with difficulty.

It appears Micronas and then TDK acquired the WIS chip rights and it might have been taken off the market or folded into another portfolio.. but WIS based hardware compression capture chips disappeared after XP support basically ended for things like the Plextor M402 and related series.

ATI had a go at continuing MPEG2 hardware compression until the end of that company being acquired by AMD. ATI had the 550, 650 and later 750 chips with mostly Windows Media Center support under XP and then Vista.

Lumanate would produce the excellent Dell Angel MPEG USB series, which targeted the Windows Media Centers worked with Monsoon SnappySoft capture software.. and AMCap (after a fashion).

AverMedia of Taiwan and Hauppauge of New Jersey/China (?) are still offering products and had a long line of offerings both with recognized and individually proprietary and their supported versions of capture software.



1/03/2021

Categories for Render, Capture and Nodetypes Microphones, Line Connectors and Speakers

In addition to the KSCATEGORY_AUDIO Categories, the INF file can also "decorate" the device driver as having other interfaces that the builder might want to probe.

These can help in directing the builder to probe and fill out a description for the device when making its Audio Endpoint.

For some of these types it attempts to discover abilities and interconnected topologies so that the Endpoint makes better sense to the end user when complete.

Video capture and Audio capture applications typically try to "find" or make sense of the resources of a video capture card by strumming theses "inventories" of endpoints and interfaces when building up a list of choose-able sources and sinks of video and audio data.

Video Capture applications aren't very sophisticated when looking for sources beyond the current year in which they are written.. so a re-think or re-conceptualization of how to present usable resources can lock them out of running properly on newer re-thought operating systems.

"Some" device drivers hook themselves into the default audio or "desktop" when loaded.. some do not.. those that do are easier to support with legacy capture software because they merely have to capture from the default channels of the system.

UVA and UVC seems to be the latest "re-think" in the way video and audio information is presented as a resource to the operating systems and programs. And they are generally across USB serial buses.

Since Analog video capture is mostly long gone.. supporting moving between XP to Vista and 7 or 8 and 8.1 is unlikely to be something that can be done for much longer. Even the device driver signing methods and keepers of the hardware and kernel keys is consolidating at Microsoft.. and locking more and more of the developer community out.. which could lead to an upheaval in computer programming moving forwards.. abandoning Microsoft and Apple products for a more flexible and open system.. unlikely Linux since that too seems to have started blocking flexible development models. A stagnation of original thinking seems to be beginning a new dark age.

Ironically the XP operating system without hardware device driver signing.. is the easiest to develop for.. and the ReactOS may eventually prove to be the favored operating system of the future. Its hard to imagine Microsoft will mentor and shoulder the burden of solving problems for indiscernible and not immediately profitable motives long term.

Why Video Capture boards don't display Audio Endpoints in Vista and 7

I'm real fuzzy on this at the moment.

But it appears when going from XP to Vista, they re-thought how Directsound or Directshow audio devices were presented to programmers.

They invented something called the "audio endpoint builder service" which monitored the PnP insertion of device drivers, registering various characteristics about loaded device drivers in the registry or class tree.

When one added itself to the "KSCATEGORY_AUDIO" class category, it went to work "probing" the "device" attached to the system by inspecting its pins and their default parameters.. automatically constructing an "Audio Endpoint".

These virtual "Audio Endpoints" were conceptually thought to be "better" than using the Directshow API which was based on filters for accessing and manipulating the hardware on a device directly.

Instead, users and programmers were able to "think about" the Audio Endpoint as a fully fleshed out object which they could use more generic commands to control to setup an "Endpoint Session" which was assumed "Blocked" until it was "un-Blocked" and began streaming data, either In or Out of its device.

Once these Endpoints were constructed, they populated the Sound Control panels where they could be designated as the default Playback or default Recording Endpoint.. 

The reason video capture cards do not appear as Audio Endpoints, is apparently because they're device driver INF files do not "decorate" themselves as "KSCATEGORY_AUDIO" class type.. and the "audio endpoint builder service" ignores them and does not build up the Endpoints the Sound Control panels use to populate the choices in the Playback and Recording endpoint choices.

It seems the "pins" for In or Out should also be decorated with descriptions of whether they are WaveOut or WaveIn or some other type.. but mostly the rest of the Directshow description should map to parts of the constructed Endpoints, since the Vista revised "re-conceptualizing" allowed for supporting legacy communications protocols and interfaces.

So.. its possible their devices will just work once their device drivers are revised to carry the badge of "KSCATEGORY_AUDIO"

One potential problem however are "signed" device driver packages.. since they are supposed to come with a .CAT and certificate set that ascertains the device driver has not been tampered with.

It might be possible after the device driver is installed.. to manually patch the registry to "add" the device driver/device to the "KSCATEGORY_AUDIO" by adding its guid.. if thats how it works.. but might also need to do that for its Pins.

Win7 x32 seemed easier to avoid device driver signing problems for a test.. or self signed was at one time possible with Win7 x64


12/05/2020

Wis Tech WISGO7007 video capture 64 bit drivers

 

The Wis Tech GO7007 video capture hardware compression chip was put into a lot of Video Capture devices from 2002 to about 2009.

It was popular during that time because is cost about $10 a chip in bulk and only performed a "Pre-Compression" to a stream format that could prepare it for formal protocol compression into a recognizable standard by a PC attached through a bridge chip like Firewire IEEE-1394 or USB 1.0, 2.0 or 3.0

It was specifically designed as a microprocessor with DSP functions without a specific format target, but also for use in PC devices and not as a single chip solution for a DVD recorder which many other companies targeted with much more expensive chips at the time.

Mostly the "GO stream" output format was a DCT - Discrete Cosine Transform output product which many of the recognized compression products already performed prior to actually performing dissection and redundancy elimination steps. It can be looked upon as a common 'root' step of filtering high frequency 'noise' out of a frame of video before overhauling it in greater detail to compressed frames and groups of picture to further reduce video stream size.

This lightened the 'load' on the PC bus used to bring the stream into the PC for further processing, be that a Mac or traditional PC.

To be sure this could be ISA, PCI or PCI express busses as well as Firewire or USB external connections.

This led to the term or idea of the Personal Video Recorder or (PVR) which gained traction at the time. As opposed to the more familiar Digital Video Recorder or DVD recorder.

Unfortunately with the shift away from 32 bit architecture to 64 bit architecture beginning with Windows Vista and later Windows 7 and 8, 8.1 and 10 many of these devices lost device driver support after Windows based on 32 architecture fell out of favor.

The Plextor ConvertX and ConvertPVR or ADS Technologies and StarTech derived products found themeselves without a device driver and many went up for next to nothing on places like eBay for those who continued to use 32 bit machines.

A couple of vendors like ADS Technologies did produce candidate 64 bit Vista device drivers, which do run in Window 7 x64, however they are hard to find online and ADS Technologies never finished to the point where the candidate device drivers were actually signed with a Microsoft Device Driver signing certificate and can only be used in Test mode.

StarTech which sourced a device called USB2TVTUNER "may be" the last vendor that had an actual robust 64 device driver with signing for Vista, Windows 7, 8 and 10 -- but it is very hard to find, and the 64 bit device drivers were only found after an exhaustive search in archive.org of a remote Mexican website for Doctors. The Startech website download for the 64 bit drivers themselves has long since been taken down and was not archived in whole to archive.org.

The WIS GO7007 was a chip that came with an SDK for Windows and later for Linux. Essentially like many designs of the time the front facing or Input section of the chip depended on a 'video signal preparation' chip, which could be as small as a single wire interface to a composite input, or as complex as a Intermediate Frequency multiplexer coming from a Broadcast Digital Adapter or 'TV Tuner'.

In general however the preparation chip would attempt to select which Input source to switch the inputs of the Wis GO7007 chip, and or route the signal around the chip if plain YUV video capture were the choice.

Then would come the Wis GO7007 chip and its processing to the stream, followed by an interface chip that supported some type of computer bus or firewire or usb. the Wis GO7007 had native support for HPI or USB interface chips and a general purpose interface to I2C or SPI (I'm not sure which). In those days a general purpose serial bus like the I2C or SPI were very popular on cards and external devices, since it required fewer traces to carry short distance serial communications between chips.

Then would come the Interface chip to the PC.

As far as I know the EyeTV 200 device was the only example of a firewire TV Tuner that used the wisgo7007 and it only worked on an Apple Mac with EyeTV software.

Many more examples of wisgo7007 use were available on the PC.

But Pinnacle has a fairly large collection with offerings for both the Mac and the PC, including many TV Tuner devices through the EyeTV software.

On the PC side WIS GO7007 is less known, but well represented. As mentioned the ADS Technologies had the DX2, and possibly the Hauppauge PVR line has some WIS offerings. Startech carried the USB2TVTUNER. And the Plextor line covered both the Mac and PC lines with multiple variants on the ConvertX and ConvertPVR standalone and tv tuner designs.

The general device driver usage of the devices were the same. First go7007 firmware 'blobs' were uploaded to the Wis GO7007 chip and reset to boot as well as other peripheral chips were programmed for their state before assuming the video capture position, and finally commands were sent over the Mac or PC attached bus to commence video capture.

Most Mac or PC attachments operated in in the Master Slave mode, where the video capture device either looped processing frames until data was retrieved, or waited silently for commands to send data.

The actual bus architecture could present possible problems in maintaining capture rate and simultaneous audio and video captures to prevent lip sync problems.

One of the major benefits of using an all in one audio and video capture chip were in that it could decide and take actions to prevent lip sync problems de-arbitraging and simplifying latent decision making processes in code on the Mac or PC, and leading to a fairly stable capture experience.

Hardware encoder chips that dedicated to one capture format or another, and that did not act as general purpose Digital Signal Processors were costly and less adaptable as new standards came out. Throwing the 'baby out with the bathwater' each time a new MPEG format or profile was announced was a common occurrence.

Whether it was a Hardware or Software, or Para-hardware solution however, a great deal of processing power had to be used to convert the analog to digital signals.. and this typically threw off a lot of heat.

Some busses could power the capture device from the bus connection, like USB or Firewire, others could not and required a separate external power supply further entangling the cable set.

The WIS GO7007 had a processing amplifier (or proc-amp) in its driver set which could change the signal processing capabilities of the chip on the fly. Including brightness, contrast, saturation and sharpness. Quixotically.. this last parameter was set to (blur) or very low in the SDK and often left that way. An unobservant device driver writer would over look this 'bad' setting and result in a default video capture bordering on 'Terrible'.. but at the incredible price of $10 a chip.. it was assume par for the course.

Changing this value manually within the capture driver after startup (which always resets to the 'terrible' setting on reboot) provides some [Spectacular] video capture results.

How to Turn Bluetooth Radio Back on, How to Bring the Bluetooth Systray Icon Back

 

How to Re-Enable Bluetooth Radio when its disabled
and the Bluetooth Systray Icon disappears
or fails to appear on Reboot

1. Open > Control Panel
2. Double click on "Bluetooth Devices" < NOTE: "Devices not Settings"
3. Open "Tools" Menu, go to the last option called "Bluetooth Settings"
4. On the "General Tab" < the Default when opening "Bluetooth Settings"
5. [Checkbox] the Empty [_] "Turn Bluetooth Radio On"
6. Click "Apply"
7. Click "OK"

How to Restore the "Bluetooth System Tray" Applet Configuration Icon

1. Mouse to the "System Tray"
2. Right Click on a Systray Blank area to get "Properties"
3. Click on "Customize notification icons
4. Uncheck box [_] "Always show all icons and notifications on the taskbar"
5. Find the "Csr Bluetooth TrayApplication / CSR Bluetooth"
6. Change the Behaviors to "Show icon and notifications" (not) "Only show notifications"
7. Recheck the  [_] "Always show all icons and notifications on the taskbar"
8. Click "OK"
9. Click "OK" to dismiss both windows
A. At least Logoff and Login to refresh the System Tray Applet Icons
B. Reboot for good effect and to initialize a proper startup order of Radio and System Tray startup

10/19/2020

4:1:1 more appropriate for 4:3, 4:2:0 more appropriate for 16:9

 In the last posting in February I came down on the side of 4:1:1 for regular normal (plain) VHS resolution capture.

I still think that is true, in particular for high velocity action sequences and where post capture Editing of the captured material may be a possibility.

 But also, the geometry of traditional SD capture renders the pixel Aspect ratio as 4:3 which is much closer to a "square" shape, than a 16:9 wide-screen pixel Aspect ratio.

 So for two reasons, 1. the limited TVL horizontal resolution of the VHS format, and 2. the shape of the pixel due to Aspect ratio.. choosing a 4:1:1 capture format may have advantages over a 4:2:0.

I am vaguely aware of a difference between pixel "display" Aspect ratio versus pixel "capture" or sampling Aspect ratio.. and that there is a terminology assigned to those differences. It can become quite confusing.

 It comes up when trying to display a wide screen formatted video in a viewer or display device without a proper attribute in the file header to indicate the intended shape of the pixels to be displayed.. aka the "wide screen attribute".

This leaves me with thinking (in simple terms) that reserving DV capture for VHS and MPEG2 capture for S-VHS is an appropriate choice.. but especially when capturing Wide-Screen movies or video that is in the wide screen display format.. it is literally focusing more of the horizontal color sampling on the horizontal wide screen major axis in that case.

Broadcast video is a whole other situation, but video capture from a VHS tape is vastly different from video capture from a Broadcast signal.. since there actually are more TVL resolution in the horzontal axis to be captured. In that case it becomes a question if 4:2:2 or 4:2:0 is the better choice since 4:1:1 would clearly not be preferred.

In the days when Broadcast signals were over NTSC this would be an interesting debate, but in the current era where transmissions are "digital" and mostly MPEG-TS or MPEG-PS it makes more sense to just capture the digital signal for storage, rather than converting back to Analog and then capturing to Digital.