u/flameborn

It's a joy to use this with screen readers, the UI is very minimalist but everything's labelled and works like a charm. Thank you!

Not that it's worth arguing with a pathological liar (see other posts where he was found out stealing demo songs, etc), but for those people's sake whose doubt flared up that Fex is not authentic. From a sound engineer's perspective:

If you know what to listen out for, AI can be very easily detected with a 99.99% accuracy as far as audio is concerned. Can't comment on text or images, alghough I am aware that there are tools that can accurately determine if a written text is likely coming from an AI.

In our case, disregarding the fact that the accent, mannerisms, intonation, and style match between all four versions (first tape capture, the tape that was sent, live tape recording, live radio version), one thing that can't be faked is the age. for the vocals, even with AI. The only imaginable possibility here is if Fex's vocals were used as a model for something like a retrieval-based voice transfer, where the original recording's style was transfered to a voice model captured from an early Fex vocals tape. Supposing that we are fooled into believing that this AI version is sang by a human and not created by an AI, now they would need to create the instrumental version. This can be easily done, as they are musicians themselves. There are very good DX7 emulations having the exact same presets for example, but this also means that everything has to match up, including effects. For the live versions, they have to play and sing everything the same way as well, except now it has to be playback for the vocals, otherwise the trick would be exposed, since the vocals would have changed by 2013 and onwards.

But suppose everything works out, so now we have the fake 1985 tape version as it was sent to us. The final touch, tape emulation is actually very hard to do convincingly. Yes, there are insanely good tape emulation plugins, but they are still not on the same level as hardware with added wear that happens with time, even premium plugins like U-He Satin, Waves J37, Hornet's Cassette or Tape mk2, Softube's Tape, etc.

I firmly believe that the only people who can provide actual evidence are the members of Fex at this point. There's this saying that actions speak louder than words after all.

Ronnie's only slim chance of making himself seem believable here is AI, which is quite pathetic and he is only making it worse for himself. He doesn't realise that he's a laughing stock and he makes it worse by involving Abba too. Ronnie, dear pal, Abba 40 years later is still a zillion times more famous than you could ever be, 499 songs or not. I know, I know, it must be that stupid AI. again, from Sweden.

Yep, the local mode, which is what I am using at the moment, but this is sadly not ideal, as there are interfaces that I would not like to listen on.

Thank you. Now I know why it's happening, but unfortunately this does not bring me closer to a solution.

Thank you very much for the detailed information.

The machine I'm running Pihole on uses Caddy, which exposes the admin interface via pi.hole. I use my router's DHCP with DNS filtering, advertising Pihole as the only DNS server.

The Arch package modifies Pihole's behavior slightly, e.g. the debug token, the update feature and the -r switch have been removed from the command-line interface, however FTL should be operating the same way, which is why I posted my issue here, since changing the interface for Pihole is not Arch-specific.

No dice still, after a restart, but I'm looking into it some more. If it works for you, I imagine it should theoretically work here the same way.

Although I appreciate your offer of testing it on an Arch install, please don't trouble yourself on my behalf, I'll figure it out eventually.

My web server was configured for pi.hole, which I am not able to access at the moment, but it was very likely listening on eth0. If I set it to local via the command line interface (pihole -a -i local), it works. I'd like to avoid this though, if possible and listen on a single interface only.

It's using 252.1.

Unfortunately this does not seem to solve the issue, it still disconnects/times out, even after restarting FTL.

pihole -r is unavailable under Arch Linux, which I am guessing would allow me to reload the value.

Absolutely. Besides the update to the latest FTL, and a firmware upgrade, there were no network changes that I know of.

Some people are having this issue as well on Arch Linux ARM here: https://archlinuxarm.org/forum/viewtopic.php?f=15&t=16245

I'm glad I could help. I used to play a ridiculous amount of text games, both CYOA and traditional interactive fiction, and later on, thousands of muds.

Happy cake day to you as well!

As suggested, the IFDB lists lots of text adventures, mainly interactive fiction.

Since you mentioned text files, my guess is that you're rather looking for CYOA-style games. Perhaps it was the Fighting Fantasy Project

Another possibility, and one of my favorites is Lone Wolf, through Project Aon.

A modern-ish version of CYOA is Choice of Games, though I'm only putting this out there for completeness's sake.

I'm probably missing lots of others, if you remember a game you used to play, or any other detail you could add, we could possibly narrow it down some more.

You're most welcome. Take your time and let us know how it goes whenever you can ☺️

There is a way to connect your Zoom h1n to your computer as a microphone, see here: https://www.youtube.com/watch?v=yFyWy9LUBEI

I am not sure why you have bad-sounding audio, with the default settings, you should be getting the exact same sound that you get in Audacity. I am assuming that the file you recorded into (wav, mp3, etc) is not at fault here, since you have good-sounding audio in other programs.

See if you can record with Reaper through your Zoom recorder and you get the same result as with the file you dragged in.

to put it short and simple:

• If you render in a lossy quality, no matter the bitrate, e.g. mp3, lossy m4a, ogg, opus, etc, you are going to have a copy of the original lossy quality audio in whatever format you encode. For example: a 320 KBPS mp3 is a lot lower quality than it could have been, had it been ripped losslessly from a CD. Re-encoding that to a 320 KBPS will result in a copy that has 320 KBPS of the original mp3 audio.

• If you render lossless, e.g. to flac, lossless m4a, Wavpack,,, wav, the quality will not be better, it will be just as good as the original. However, you will not lose anything. This is the best you can do.

Depending on your situation, it is okay to re-render to a lossy file, but I would personally render to a compressed lossless audio, to not lose more audio by re-encoding again. It will take up more space, but that's the price we pay for editing lossy audio. Unfortunately there are very few audio formats you can edit losslessly.

Thanks, I learned something new today.

I'm starting to slowly realize this. Theoretically, if preallocation is disabled in any torrent client, block writes should happen only once per block, which is exactly the same as copying or moving a file.

The only issue at this point is fragmentation, which also happens when writing random parts of a file on any other file system, such as ext 4.

So I likely have two options:

• Disable COW and turn on preallocation to minimize fragments, or
• Disable preallocation and keep an eye out for fragmented files, defrag via auto defrag or manually when needed. In addition, make sure there's enough capacity when starting a download. This is essentially the same as on ext 4.

Ah, the fragmentation. This is good to know, thanks.

Thanks.

Snapshots would indeed complicate things more, in this case I luckily don't have to worry about them.

This would reduce fragmentation, but I guess there are no ways of avoiding multiple block writes, either by moving or doing preallocation.

One can't have everything, as they say. Thank you.

This is very insightful, thank you! The drive in question is just a hard drive.

Interestingly, the Arch wiki suggests preallocation (https://wiki.archlinux.org/title/RTorrent):

rTorrent has the ability to pre-allocate space for a torrent. The major benefit is that it limits and avoids fragmentation of the filesystem. However, this introduces a delay during the pre-allocation if the filesystem does not support the fallocate syscall natively.

Do you have COW enabled on drives where you use torrent?