tripflag

I've had luck ripping VCDs on Linux with vcdxrip -v -p -i /dev/sr0

Alternatively, first creating a bin+cue on windows with imgburn (ISO won't do!) and then vcdxrip -v -p -b the.bin -c the.cue

Having been such a popular format in Asia, a rich assortment of VCDs keep showing up at flea-markets in Norway; both original productions sold as VCDs, as well as "silvers", that is, exceptionally poor-quality pirated movies, often amusingly so. A popular example is "Star Wars: Backstroke of the West", with subtitles machine-translated from english to chinese, and then back to english.

VCDs, like DVDs, tend to have multiple audio tracks with different languages, even though the format doesn't actually support that technically. Take "yangtze three gorges" for example; a Chinese nature documentary with perfectly cheesy intros and outros. There was three "audio tracks"; the original Chinese, plus English and Japanese dubs. VCD only allows for a single audio track, so you find Chinese in the left channel, and English on the right. Televisions sold in Asia would have a toggle-switch on the remote to select one of the two audio channels to duplicate to both speakers.

Of course, having two dubs, the Japanese dub was made by having another copy of the whole video file, except with Chinese+Japanese.

For context, the Python workload was a general-purpose fileserver with file indexing and image thumbnailing, largely IO-bound. Switching from mallocng to mimalloc resulted in a slight speedup (150% of baseline), but over twice the memory usage, going from 250 to 670 MiB, primarily for thumbnailing. Some pathological cases (libvips calling imagemagick to decode heif) was a 10x multiplier.

There was multithreading, and yes, mallocng visibly became a bottleneck beyond 5 threads. However already at 3 threads there was diminishing returns for both allocators, so this was not an issue in this case.

The speed gain was hardly noticeable in practice since the program was already plenty fast, but the additional memory usage was a very real inconvenience.

it's a tradeoff; mallocng does have benefits as well -- for example it uses less than half the amount of RAM compared to mimalloc and glibc for certain Python workloads. While yes it is a bit slower, I prefer mallocng in many cases.

Cool! Out of curiosity, since qr-codes can contain binary data -- rather than base64, have you tried inserting the file as-is? That way you could do away with the ASCII separator and have a binary header as well. This would spend less frames for the same amount of data, but I'm not sure if it would be computationally cheaper. The other alternative would be the alphanumeric mode of qr-codes, but then you lose lowercase.

But what if you are leaving the page because you changed your mind, and don't wish to save the changes after all? This, for me, is the common case, so i would not want the browser to suddenly commit an unfinished draft.

Hence my question -- my belief was/is that all of the escape-sequences mentioned in the article will work on 99.99% of all terminals, with the exception of 256-color. Assuming this is true, IMO the remaining 0.01% does not justify introducing another dependency (ncurses -> tput).

Aside from the 256-color section, I believe all of the examples given in the article are basic sequences which are supported in ~every terminal. Are you aware of any notable terminals where that is not the case?

Maybe I've been lucky, but I've written plenty software that blindly shoots CSI's at the console and still haven't hit any snags. Especially convenient when the channel is unidirectional; curl ocv.me :)

h264 still makes sense in some applications because it is relatively computationally cheap, and has very wide adoption in both software and hardware.

in the case of HEVC/h265, one of the main reasons today is Apple using that codec for photos (heif/heifs/heic/heics); it never came close to the popularity and adoption that AVC/h264 did. AV1 is superior to h265 in most ways; there is little technical reason to use hevc.

Good news is there are ongoing efforts to make that happen; https://github.com/SnapXL/SnapX

in my case, I use zed for almost everything, and vscodium for three things:

search across all files; easier to navigate the results with the list of matching lines in the sidebar, and traversing the results with cursor up/down, giving full context

git; side-by-side diff, better handling of staging, and doesn't automatically word-wrap commit messages (I prefer doing that myself)

editing files which have a different type of indentation than what is configured in zed, since zed does not yet have autodetect

Microsoft has been making it harder to run their proprietary python plugin in vscodium, which I was relying on to provide hints from pyright. That's something I didn't want to deal with, so I just jumped ship.

There are some things I miss from codium, and I still capitulate back when editing files with nonstandard indentation because zed doesn't yet have autodetect for that, and also its git-staging / diff-view isn't as good yet, but aside from those it's a mostly alright experience.

Just to clarify that the 8 security announcements are not open issues; they are announcements that a new release has been made which fixed something security-related. I'm doing my best keeping a good track-record for fixing such issues in a timely manner, and the turnaround time for severe issues has so far been <=4 hours.

As for the open issues, 140 are feature suggestions, and 36 are currently classified as bugs. I'm hoping to start popping the list of bugs soon after I'm back home from my vacation which will be soon (am typing this from the airport waiting to board!)

Ah, a small correction regarding this... What I /meant/ to say in the video was that a lot of the INITIAL code was written this way, so the statement is mostly true for v0.2.3. Since then I've primarily been using vscodium (and recently zed) on my linux laptop, but I still tend to do quick prototyping on the phone when i get a bugreport or a sudden idea.

That part of the video was recorded at 3am as I just wanted to "get it done", which also explains the other mistakes (typos, phrasing). I tried to replace the audio-track of the video when i noticed the phonecoding part after uploading, but turns out that's not really possible, so I figured what's done is done, impractical as it is -- I've been trying to offer this correction when I see it come up.

So my workflow right now is mostly zed and pyright+black, and no AI/LLM except for localization of new strings to languages I don't speak.

Combining copyparty with Syncthing is not something I have tested extensively, but I know people are doing this, and I have yet to hear about any related issues. It's also a usecase I want to support, so if you /do/ hit any issues, please give word! I've briefly checked how Syncthing handles the symlink-based file deduplication, and it seemed to work just fine.

The only precaution I can think of is that copyparty's .hist folder should probably not be synced between devices. So if you intend to share an entire copyparty volume, or a folder which contains a copyparty volume, then you could use the `--hist` global-option or `hist` volflag to put it somewhere else.

As for high CPU usage, this would arise from copyparty deciding to reindex a file when it detects that the file has been modified. This shouldn't be a concern unless you point it at a folder which has continuously modifying files, such as a file that is currently being downloaded or otherwise slowly written to.

> I also miss Filerun's "Request a file" feature which worked very nicely if you just wanted someone to upload a file to you and then be done.

With the disclaimer that I've never used Filerun, I think this can be replicated with copyparty by means of the "shares" feature (--shr). That way, you can create a temporary link for other people to upload to, without granting access to browse or download existing files. It works like this: https://a.ocv.me/pub/demo/#gf-bb96d8ba&t=13:44

Hey o/

Yup, this is 97% just me hacking away in vscode -- I use pylance and the debugger but have everything else disabled, easier to focus that way. The only time I use any sort of AI/LLM is for translating new strings into Chinese, since it seems decently capable at that :-)

The remaining 2% is friends coming up with new usecases/features, and sometimes finding bugs.

But now that the project got way more attention than I'd anticipated, pullrequests have started appearing, so it doesn't look like those statistics will stay true for much longer! Really cool having more eyes on it spotting the things I overlooked, really enjoying that.

it's also inconvenient for Norwegians and Danes, since Ø is part of our alphabet. Slightly jealous of Sweden since they write it like Ö instead... Either way, big fan of dotted zeros for that reason.

To be fair, it has been persistently offline for the past year or so every time I checked, so I'm not surprised that other people would jump to the same assumption.

I recall towel.blinkenlights.nl mentioned you would get a different version of the video (with colors) if you connected from IPv6. I've found rips online of the plain grayscale version, but not the colored one.

Anyone happen to have a recording of it?

mods are still alive, and crazier than ever -- proof that 4 channels is all you need! https://www.stef.be/bassoontracker/?file=ma-205456

if you stop sending data entirely, browsers tend to drop and reopen the connection after a few minutes, assuming something got stuck along the way. Throttling seems to prevent that nicely.

Yep, and the server bandwidth can become a bottleneck if the peers are fast enough, so true peer-to-peer is still the better choice, or something webtorrent-based if multiple people are grabbing the same file.

But there's been enough last-minute submissions of DJ material by now that I'm still happy it was added as an option :-)

> There are services which allow you to upload via CLI and download via web browser, but they host your file so you have to wait for the full upload to finish before sharing the link.

There are exceptions to this; I've been making copyparty[1], an httpd which lets you start downloading a file that is still being uploaded[2]. If you catch up with the uploader, it'll throttle the speed so the browser doesn't drop the connection. Uploads and downloads can be done through browser and/or cli.

I recall there was at least one other alternative with similar functionality somewhere on the awesome-selfhosted list, but I'm failing to find them right now... It was prominently mentioned in the project's readme, but maybe that's no longer the case.

[1] https://github.com/9001/copyparty

[2] https://a.ocv.me/pub/g/nerd-stuff/cpp/2024-0418-race-the-bea...

There's also the fact that an NVRAM variable is never overwritten inplace; the new value is written elsewhere, and the pointer is updated to use the address of the new value. This is probably mainly for wear-leveling, but I guess it could also introduce fragmentation?

Just an observation from when I was debugging a board that selfdestructed when booting a particular efi-file so I had to dig into the flash contents to figure out why, but I think this particular code was straight from tianocore.

I played a bit of Super Mario 64 using an early version of Daedalus, so it was more than a rumour :>

Granted, it ran at about 80-90% realtime speed, and audio was a no-go, but maybe that improved in later releases.

I have very fond memories of XionPlayer; https://www.xionplayer.com/

The amount of visual flare that thing managed to produce in the heydays of WinXP was stunning, felt like operating a scifi-movie prop with all of the alphablended animations shooting out of the player window at times.

Kaitai Struct has an online demo which basically does this; https://ide.kaitai.io/

Yes; i use this trick to display an upload progressbar (progress-donut?) using a bit of JavaScript: https://github.com/9001/copyparty/blob/c5988a04f/copyparty/w...

but note that browsers rate-limit you to approx. 1 update per sec

One trick not mentioned in the article is to repeat the ddrescue with the same CD in different drives; this almost entirely saved my unreadable CDs, as no single drive could read them entirely.

My biggest savior was a Pioneer BDR-AD07BK which managed to read some discs that other drives couldn't even get the TOC off!

I wrote a gnu-ddrescue wrapper back then to avoid accidentally resuming a read to the wrong iso (only ever tested on alpine): https://github.com/9001/usr-local-bin/blob/master/miso

I just wanted to make sure I wasn't passing up on a free 400% boost or something :-) but it was already running plenty fast, so it was entirely out of curiosity.