I used dvgrab to ingest my old tapes, and ffmpeg and avisynth/QTGMC to de-interface and encode files for easy viewing (though I keep the original .dv files).
The biggest issue I ran into was that while the audio and video were properly synced up in the original .dv file (due to it being an interleaved format), when I re-encoded the videos, the audio and video would drift out of sync as the video went on.
I was able to fix the sync issues by using dvgrab to split the original dv file into a bunch of 3 minute chunks. I then wrote a script to extract the audio track from each chunk, pad the end of the audio with milliseconds of silence to the exact length of the video track, combine the padded audio tracks, encodes the combined track, and muxes the fixed audio track with the encoded video. This worked really well; the silence padding is imperceptible, but the audio and video are still in sync - even after 2 hours.
A final point that needs making is that doing anything with dv files in ffmpeg (even -c:v copy) destroys the SMPTE timecodes embedded in the original file, making it much harder to split by scene.
Just because I've dealt with this exact issue in the past, it may have been a 30fps vs 29.97fps issue. For me the audio was a fixed length, but the frame rate was SLIGHTLY too fast. The problem can manifest as either too slow or too fast depending on which side is expecting 30fps vs 29.97fps.
I think it was just clock drift on the camcorder during the initial recording, as I'm pretty sure I tried adjusting the frequency of the audio track to make it the same duration as the video track, and the A/V sync was still wrong.
I'm so glad the audio and video tracks are stored interleaved, as it made my solution possible, and the results I got were great. By splitting the interleaved video into small enough chunks, padding the audio, and cutting it exactly to video length, the padding was practically imperceptible.
The only issue I ran into was that ffmpeg can't cut audio with any real precision. I eventually figured out that I could dump the audio track to a headerless PCM file, calculate the exact byte offsets for my cut points, and cut them with perfect precision using the head and tail commands from GNU coreutils. This was perfect because I was able to use the cat command to combine all of the padded audio chunks into a single raw PCM file, which I then made an AAC encode of with ffmpeg to mux with my original encoded video track.
Ffmpeg's dvvideo implantation is unfortunately just broken and mangles timecodes, even if just doing a stream copy from dvvideo to dvvideo without any re-encoding.
Fortunately, dvgrab does allow you to take the original .dv file and generate a .srt subtitle track with time stamps that you can mux into your encoded files.
I built a revolutionary AI-powered weather forecaster. Unlike other similar websites, WeatherZOID runs entirely client-side, thus massively improving scalability and reducing hosting costs, allowing the site to remain ad-free forever.
The weather forecasts seem to have similar accuracy to the forecasts delivered by Google, but unlike Google's forecasts, if the first forecast generated by WeatherZOID is wrong the first time, you can get an accurate forecast by pressing the "Get Weather" button an indefinite number of times.
I would recommend VyOS Stream for this situation. It has better performance and hardware compatibility than *BSD-based software routers, and it also has a nice CLI that is syntactically similar to Vyatta and EdgeOS (found on Ubiquiti's Edgerouter line).
In additon, compared to PF/OPNsense or OpenWRT (Linux based), you have more control and exposure to the underlying network concepts with VyOS. You're not configuring the kernel manually, but you still learn quite a bit.
I fully agree. Similar to killing bacteria with antibiotics, Attempting to idiot-proof machinery only leads to the creation of idiot-proofing-resistant idiots.
We need to move back to putting users back into full control. Machines (including computers) should ALWAYS respect the input of the user, even if the user is wrong.
If a person shoots themself with a gun as a result of their incompetence, we don't fault the gun manufacturer for not designing the gun to prevent auto-execution. If you can't operate a firearm safely, you shouldn't attempt to operate a firearm.
Similarly, if a person deliberately points their car a solid object and accelerates into it, the actions of the operator shouldn't be the car manufacturer's responsibility. We need to get rid of ESC, ABS, AEB, etc. These features have created a whole slew of drivers who speed headfirst into the back of stationary drivers and expect their car to stop itself. This works right up until a sensor fails and the operator flies through the windshield (usually people like this don't wear seat-belts). If you can't drive, you shouldn't be driving until you rectify your incompetence.
Similarly, phones and computers should respect user input. If a users wants root access to their personal device, they should be able to get root access. If a user runs "rm -rf --no-preserve-root /" as root, the device should oblige and delete everything, since that is what the operator instructed it to do. If you can't be trusted to use a computer, you shouldn't be using a computer until you rectify your incompetence.
The lack of accountability in modern society is disgusting, and it leads to much deeper societal problems when people refuse to better themselves and instead expect the world to shield them from their willful ignorance.
I was with you right up until "We need to get rid of ESC, ABS, AEB, etc.".
That is unreasonable. ABS, ESC, and AEB all exist to interpret what the driver intends. The driver does not intend for their wheels to lock up, that's why ABS exists, nor does the driver intend to skid. You can argue that AEB does not reflect the will of the driver, but it can also be disabled.
I was admittedly a bit hot-headed when I wrote the original comment, but the critical qualifier in all of this is that these driver assist technologies should be optional and easily disable-able in a persistent manner, with a dashboard warning light to remind you that they're disabled.
In a lot of modern cars, there's no straightforward way of fully disabling ABS, traction control, electronic stability control, etc. There are certainly situations where they may be helpful, such as in a top-heavy truck with an open differential, but ABS and traction control systems can pose problems in other situations, such as in snow. Especially in the case of RWD coupes with limited-slip differentials, a bit of skidding may be an asset, provided the driver knows how to correct for oversteer. Even in FWD cars, ABS can sometimes be a detriment when stopping in snow, as the rapid automated brake-pumping can dislodge the snow you were otherwise going to be holding steady on.
Ultimately, I'm opposed to driver assist features being forced onto drivers who don't want to use them. I'm also opposed to teaching people how to drive with these assistance features. It's a lot like teaching students to use AI chatbots to do their work instead of teaching them to do their work themselves.
Is this new? It seems like this sort of thing has been going on for a while. A lot of the products are incorrectly labelled as containing amanita muscaria, but contain cannabinoids such as Δ8-THC and/or Δ9-THC and/or 4-substituted N,N-dimethyltryptamine derivatives, such as 4-AcO-DMT and sometimes psilocybin and psilocin themselves, in spite of their status as schedule I controlled substances.
The lack of labeling enforcement is really a problem. Genuine amanita muscaria mushrooms are a lot more like alcohol than psilocybin in terms of effects, and if you didn't know better, you could easily take a few to relax at the end of a stressful day and end up freaking out instead.
A lot of the older hybrids use NiMH batteries. With that being said, a replacement traction battery for a 2nd gen Prius isn't that expensive, at least compared to newer hybrids/EV batteries. The second gen Prius is practical, affordable, and reliable (assuming proper maintenance).
The biggest issue with the Prius (at least for the years in my price range), is that the driving experience is liable to make one fall asleep at the wheel. They're the perfect cars for monks; if you're willing to forego all earthly driving pleasures, you can get high 40s mpg.
My grandmother drove a Prius, and there was a stir in my extended family as to whether she should still be driving, as she'd been seen going 20mph below the speed limit and was driving pretty far to the right side of her lane.
I got the opportunity to drive her Prius and promptly found myself alternating between going too fast and going too slow. Between the awkward pitch of the windshield and the gross-feeling electric power steering, I wasn't the best driver either. I never have any of these problems in my 2005 Honda Civic LX or my family's 4-cylinder 2011 Ford Ranger. The Prius felt like one of those stoned driving simulators that police departments bring to high schools in an effort to prevent DUIs.
I like the idea of hybrids and EVs, but it's hard to justify completely losing the pleasure of driving for 10 extra mpg. For all I know, newer models may have improved this, but they're still to expensive for me to pay any real attention to.
Finding it's half the fun! Going out walking by a creek/river on a warm, rainy spring day is kind of an antidepressant in its own right. When you find a patch of Ovoids and pick a few, it's just all the better.
Calling the Prologue "Honda's EV" feels like a huge stretch. The Prologue was a rebadged GM vehicle that served strictly as a compliance car for meeting CAFE standards. Now that the CAFE standards have been rendered toothless, there's no longer a need for that deal.
It was "Honda's EV" in the sense that it was the only EV with a Honda badge you could actually buy. The three canned models mentioned in the article never even made it into the market.
Europeans and the Japanese were able to buy the Honda e for a few years - this article wrongly states another unreleased model as Honda's first ground up EV.
There's a few other EVs Honda produced in 90s as well, but e probably in running for first ground up new EV platform that made it to market as mass produced Honda product.
The Honda e was a massively compromised vehicle due to the tiny ~29 kWh net battery and high energy consumption. It was released in 2020 but in terms of utility it's really much more like an early 2010s EV.
> Calling the Prologue "Honda's EV" feels like a huge stretch. The Prologue was a rebadged GM vehicle …
I don't see the OP article call the Prologue "Honda's EV"? Instead, the OP article explicitly says the Prologue was both "designed and entirely built by GM."
That's separate from where the OP article first states that Honda killed three other specific models "that were the company’s first ground-up EVs".
OBBB removed any fines for violating CAFE standards. They still exist technically, but it'd be like getting a speeding ticket but the fine is always $0...
CAFE killed small trucks in part, tariffs in another part, but US manufacturers are the real reason small trucks are dead.
US manufacturers want margins, and they're not getting margins on little, efficient cars. They get enormous margins on gigantic trucks that start at $55,000. Have you noticed that all the sub $20k cars went away from all the manufacturers around COVID?
Ford makes the Maverick, which is a small truck. They were priced very reasonably at release, at $19,000 or so. However, Ford didn't make very many of them, and the ones they did make got up to $15,000 over MSRP from the dealers, who scalped them. Why would Ford want to cannibalize their pricy gigantic trucks when they know that they can get their $50k asking price because there's nowhere else for people to go?
>Why would Ford want to cannibalize their pricy gigantic trucks when they know that they can get their $50k asking price because there's nowhere else for people to go?
Why isn't Ford worried that Chevrolet, Toyota, Ram, or Nissan will bring back a small and cheap U.S. built pickup? Is that because all manufacturers are afraid of cannibalizing their more expensive offerings? Are they all colluding? Or do not many people want small pickups? I guess if the Slate becomes a breakout hit, we'll know that people really want the smaller pickups.
Neither GM, Chrysler, or Ford wants to hurt their expensive offerings. Toyota and Nissan have less expensive offerings, but can't bring them here because the tariffs make them much less margin, and the CAFE standards kill the rest off.
The Chicken tax didn't kill the domestically manufactured Ranger and turn the Colorado into the huge thing it is today.
CAFE killed them too. You can't have a small vehicle that gets fuck all MPG because it's built like a tank to do work. You gotta have a bigger one that gets slightly worse MPG but has a way huger footprint in order to make the math math.
This didn't just kill compact pickups for 20yr. It also killed the Chevy Astro (the most "fullsize work van" of the minivans) and why you'll never see a car with a giant overhanging cargo area again.
That’s not really sufficient explanation due to vehicles manufactured in the USA, CA or MX being exempt, and yet there are no small vehicles being made and sold in the USA in any large volume (despite clear demand).
My understanding is that this is due to fuel regulations being enacted by size and weight where it’s simply easier to make bigger vehicles.
MicroG does an excellent job at reimplementating most of Google's proprietary APIs on the client side.
I don't know how feasible this is, but it would be cool if there were open-source drop-in replacements for Google's server-sided APIs that app developers could use to replace Google's services with alternate servers running open source software.
The best solution for this is to buy a $30 burner phone at Walmart and use it unactivated, tethered to your main de-Googled device. You can use the burner for only tasks requiring Play Integrity.
Make sure to leave one star reviews on all such apps that you run into.
Yes. However, I already carry a tethered hand-me-down quarantine phone where I install my work apps and undesirable apps like Whatsapp (for those loved friends and family that can't or won't install Signal). Carrying a third phone for "Play Integrity" starts being a bit much.
Anything movement that requires people to routinely acquire a second phone is doomed to failure (in the “this will never become a mass movement” sense)
The biggest issue I ran into was that while the audio and video were properly synced up in the original .dv file (due to it being an interleaved format), when I re-encoded the videos, the audio and video would drift out of sync as the video went on.
I was able to fix the sync issues by using dvgrab to split the original dv file into a bunch of 3 minute chunks. I then wrote a script to extract the audio track from each chunk, pad the end of the audio with milliseconds of silence to the exact length of the video track, combine the padded audio tracks, encodes the combined track, and muxes the fixed audio track with the encoded video. This worked really well; the silence padding is imperceptible, but the audio and video are still in sync - even after 2 hours.
A final point that needs making is that doing anything with dv files in ffmpeg (even -c:v copy) destroys the SMPTE timecodes embedded in the original file, making it much harder to split by scene.
reply