AVI files are pretty passe by now, but I'm certain there are people out there (like me) who have gotten used to Virtualdub.
Sadly, Virtualdub will load most anything (with the appropriate plugin) but cannot save much of anything. So, unless you really like everything in AVI format, you'll need a new editor.
The question is: which one?
If you like Virtualdub for it's good keyboard support, easy clipping against keyframes, processing speed, ability to clip without transcoding, or anything else, you are probably going to want an editor that works like that for .mp4 files.
Fortunately, I only had to look around for a bit.
- I looked for Windows Live Movie Maker, but it only comes bundled with a bunch of other stuff, and I did not like that. I didn't even bother trying to install it.
- I tried Filmora Video Editor. Looks like a good editor for "real" video editing, where you merge multiple video streams and so forth. But the interface and output options are nothing like Virtualdub, and it seems too complex for simple clipping. I tried to clip a file and gave up in short order.
My third try, avidemux, seems to do the job. It has an interface and behavior similar to Virtualdub, seems fast, opens everything (avi, mkv, mp4, etc) and can save without transcoding. It will clip on and off keyframes, warns you when you're cutting off a keyframe, and handles off-keyframe cuts fairly gracefully.
(I guess I should have tried avidemux before. I admit the name put me off a bit. But then again, what kind of name is "Virtualdub" anyway?)
I have not tried avidemux for items like volume correction, video conversion or other things. But so far it's looking like a nice & fast editor for simple tasks.
For reference, here's a handy cross-reference guide of the basic controls for avidemux that you'll probably want to know/use.
Virtualdub -> avidemux
--------------------------------
Next frame: Right arrow -> Right arrow
Previous frame: Left arrow -> Left arrow
Next keyframe: Ctrl-Right arrow -> Up
Previous keyframe: Ctrl-Left arrow -> Down
Start: Home -> Home
End: End -> End
Mark beginning: [ -> Ctrl-Page up
Mark end: ] -> Ctrl-Page down
Save: F7 -> Ctrl-S
Not guaranteeing I got all of those correct for Virtualdub, but they should all be correct for avidemux. Happy clipping!
Saturday, September 10, 2016
Wednesday, September 7, 2016
Lexmark CS510 series won't draw / pull paper from alternative paper tray
Problem: CS510 series won't pull paper from any available tray automatically. Instead, it says something like "Load Tray 1 Plain A4", even though Tray 2 has paper in it. Or, maybe, vice versa.
Related: You've loaded the all trays / the only tray with paper, but the printer says you need to load it again, saying something like "Load Tray 1 Plain A4" or similar.
Solution: The CS510 doesn't auto-detect the loaded paper size(s) from the trays directly. Instead, you have to go to Settings/Paper Menu in the printer web server to set the paper sizes.
It will then "know" that one or more trays are holding the correct paper size for your print job. It will then stop complaining that you need to load a particular tray with a particular size.
This will also fix cases where you've loaded letter and print to letter, but the printer "thinks" the tray holds A4, or similar mix-ups.
This will obviously not work if a multi-tray printer is loaded with different paper sizes for different jobs. You can't expect, nor likely want, the printer to print letter size when the only available paper is legal size (or vice versa).
This shouldn't be an issue with a printer that's been in use because it presumably has been set up before, and will therefore "know" what paper has been loaded. But a new printer will assume all the trays are European A4 size. Which is just blinding if you are in Europe (or the UK/Switzerland/Norway/etc.) but not so great if you are over the pond.
Related: You've loaded the all trays / the only tray with paper, but the printer says you need to load it again, saying something like "Load Tray 1 Plain A4" or similar.
Solution: The CS510 doesn't auto-detect the loaded paper size(s) from the trays directly. Instead, you have to go to Settings/Paper Menu in the printer web server to set the paper sizes.
It will then "know" that one or more trays are holding the correct paper size for your print job. It will then stop complaining that you need to load a particular tray with a particular size.
This will also fix cases where you've loaded letter and print to letter, but the printer "thinks" the tray holds A4, or similar mix-ups.
This will obviously not work if a multi-tray printer is loaded with different paper sizes for different jobs. You can't expect, nor likely want, the printer to print letter size when the only available paper is legal size (or vice versa).
This shouldn't be an issue with a printer that's been in use because it presumably has been set up before, and will therefore "know" what paper has been loaded. But a new printer will assume all the trays are European A4 size. Which is just blinding if you are in Europe (or the UK/Switzerland/Norway/etc.) but not so great if you are over the pond.
Saturday, September 3, 2016
Battery life of the 1byone Driveway Alert Sensor system
This information would be good to know for anyone considering this system, but does not seem to be available.
I measured two sensor samples as follows:
- Standby (active): 25 uA max
- Detect: 16.2 mA max for about 2 seconds
It's not actually 16 mA for the full 2 seconds, but that's close enough. Especially since the 2 seconds might be anywhere from 1 to 3 seconds - I did not bother to measure more accurately than that.
The sensors run on AAA cells, which I personally hate because of their relatively low capacity. But, running the numbers, the effective capacity of AAAs should run these sensors for a very long time.
Assumptions:
- Due to self-discharge and temperature effects, cells will only deliver 75% of their rated capacity.
- I estimated alarm consumption at 16 mA for 4 seconds. This is twice as conservative as the ~2 seconds I estimated from observing the unit current.
These work out as follows:
Using 1000 mAh alkaline AAAs @ 75% of rated capacity:
- 1,000 detects: 24 months @ 1 detect/day
- 1,500 detects: 21 months @ 2 detects/day
- 2,000 detects: 18 months @ 3 detects/day
- 2,500 detects: 13 months @ 6 detects/day
- 3,000 detects: 9 months @ 10 detects/day
- 3,500 detects: 5 months @ 19 detects/day
- 4,000 detects: 1.7 months @ 75 detects/day
I would hope the 75% derating is conservative, but possibly not. Newer alkalines do have a better shelf life than older types, but they are not known to be especially shelf-stable or stable under low current loads. Freezing temperatures may also affect them.
Reviewers don't give any numbers on how long the sensors last, but I have the impression that 3-6 months may be typical. Which, given how conservative the above numbers are, would theoretically put these people in the range of 20+ detects per day. Given that the sensors do tend to false under certain circumstances, this doesn't seem at all unlikely. Better positioning and setup might greatly extend battery life.
From this, and assuming 15 detects/day at a more realistic 2.5 seconds/detect, alternative cells will give approximately the following lifespan (all derated by 75%):
- 1000 mAh AAA cells: 10 months
- 3000 mAh AA cells: 2.5 years
- 8000 mAh C cells: 6.8 years
- 15000 mAh D cells: 12 years
It is pretty clear that any way you cut it, larger (but still cheap) alkaline cells will dramatically increase the performance of the sensors. Which is what you would expect, except that the expected time for puny AAAs is already so large, C and D cell run times go through the roof.
You would obviously have to hack these units to attach to these larger cells, but this is not hard. See the interior of the sensor, where there is ample room to put additional wiring and a jack:
The main problems would be how to house and mount the larger battery pack so it's accessible, doesn't look bad, and is not subject to weathering, damage or vandalism.
I initially purchased lithium AAAs in an effort to get a better battery life - especially in the winter months - but they are very expensive. Adapting to AA, C or D would have probably been less costly, and will still be less costly in the long run. I'd also rather change the cells at my leisure in the summer rather than in the dead of winter.
With these numbers you could probably easily use NiMH cells, if you don't mind changing the batteries a bit more often. At about 15-20 detects/day you should get about 4-5 months (or so) out of them, which isn't bad at all given that they can be used over and over again. NiMH AAAs would give maybe 6-8 months, while NiMH C and D will be quite a bit longer.
Per the calculations, at 20 detects/day, Eneloop AAAs @ 800 mAh will last about 6 months, while AAs @ 2,000 mAh will last about 15 months. Eneloops are pretty stable with low self-discharge, so the 75% derating should be fairly representative over the expected time spans.
Even assuming it is off, or you get more detects than expected, 9-12 months of life from a single set of rechargeable AAs is not bad at all. And they are a lot less chunky than C or D-size cells.
These numbers also mean that if you have a high-traffic area, battery life drops precipitously. For example at 75 detects/day, you can expect to get six weeks, and around 100/day you'll get about 40 days from alkaline AAAs.
If the sensor is always going off, expect to change cells very, very often, or adapt the sensors to use an AC adapter instead. At 16 mA peak nearly any 4.0V-5.0V adapter will do the job.
[Update 2017-06-26]: Lithium AAs lasted the whole winter and beyond, Sept to July without issues.
I measured two sensor samples as follows:
- Standby (active): 25 uA max
- Detect: 16.2 mA max for about 2 seconds
It's not actually 16 mA for the full 2 seconds, but that's close enough. Especially since the 2 seconds might be anywhere from 1 to 3 seconds - I did not bother to measure more accurately than that.
The sensors run on AAA cells, which I personally hate because of their relatively low capacity. But, running the numbers, the effective capacity of AAAs should run these sensors for a very long time.
Assumptions:
- Due to self-discharge and temperature effects, cells will only deliver 75% of their rated capacity.
- I estimated alarm consumption at 16 mA for 4 seconds. This is twice as conservative as the ~2 seconds I estimated from observing the unit current.
These work out as follows:
Using 1000 mAh alkaline AAAs @ 75% of rated capacity:
- 1,000 detects: 24 months @ 1 detect/day
- 1,500 detects: 21 months @ 2 detects/day
- 2,000 detects: 18 months @ 3 detects/day
- 2,500 detects: 13 months @ 6 detects/day
- 3,000 detects: 9 months @ 10 detects/day
- 3,500 detects: 5 months @ 19 detects/day
- 4,000 detects: 1.7 months @ 75 detects/day
I would hope the 75% derating is conservative, but possibly not. Newer alkalines do have a better shelf life than older types, but they are not known to be especially shelf-stable or stable under low current loads. Freezing temperatures may also affect them.
Reviewers don't give any numbers on how long the sensors last, but I have the impression that 3-6 months may be typical. Which, given how conservative the above numbers are, would theoretically put these people in the range of 20+ detects per day. Given that the sensors do tend to false under certain circumstances, this doesn't seem at all unlikely. Better positioning and setup might greatly extend battery life.
From this, and assuming 15 detects/day at a more realistic 2.5 seconds/detect, alternative cells will give approximately the following lifespan (all derated by 75%):
- 1000 mAh AAA cells: 10 months
- 3000 mAh AA cells: 2.5 years
- 8000 mAh C cells: 6.8 years
- 15000 mAh D cells: 12 years
It is pretty clear that any way you cut it, larger (but still cheap) alkaline cells will dramatically increase the performance of the sensors. Which is what you would expect, except that the expected time for puny AAAs is already so large, C and D cell run times go through the roof.
You would obviously have to hack these units to attach to these larger cells, but this is not hard. See the interior of the sensor, where there is ample room to put additional wiring and a jack:
The main problems would be how to house and mount the larger battery pack so it's accessible, doesn't look bad, and is not subject to weathering, damage or vandalism.
I initially purchased lithium AAAs in an effort to get a better battery life - especially in the winter months - but they are very expensive. Adapting to AA, C or D would have probably been less costly, and will still be less costly in the long run. I'd also rather change the cells at my leisure in the summer rather than in the dead of winter.
With these numbers you could probably easily use NiMH cells, if you don't mind changing the batteries a bit more often. At about 15-20 detects/day you should get about 4-5 months (or so) out of them, which isn't bad at all given that they can be used over and over again. NiMH AAAs would give maybe 6-8 months, while NiMH C and D will be quite a bit longer.
Per the calculations, at 20 detects/day, Eneloop AAAs @ 800 mAh will last about 6 months, while AAs @ 2,000 mAh will last about 15 months. Eneloops are pretty stable with low self-discharge, so the 75% derating should be fairly representative over the expected time spans.
Even assuming it is off, or you get more detects than expected, 9-12 months of life from a single set of rechargeable AAs is not bad at all. And they are a lot less chunky than C or D-size cells.
These numbers also mean that if you have a high-traffic area, battery life drops precipitously. For example at 75 detects/day, you can expect to get six weeks, and around 100/day you'll get about 40 days from alkaline AAAs.
If the sensor is always going off, expect to change cells very, very often, or adapt the sensors to use an AC adapter instead. At 16 mA peak nearly any 4.0V-5.0V adapter will do the job.
[Update 2017-06-26]: Lithium AAs lasted the whole winter and beyond, Sept to July without issues.
Subscribe to:
Posts (Atom)