Apparently my account on the site is/was now more than a quarter of a century old... Gonna try to avoid thinking on that too deeply. :D
There's been a non-zero number of occasions since that time where I've observed situations that mirror the trust-based challenges Advogato sought to solve.
It is perhaps telling that as prescient as Raph's work on trust metrics was he later moved on to the notoriously challenging realm of font rendering--presumably because it seemed more tractable. :D
I encountered the Sony MMCD when I fell down a rabbit hole *checks literal notes* around five years ago while researching Microsoft Encarta MindMaze[0] and its related file formats.
It turns out the data associated with MindMaze (& other encyclopedia data) changed storage format over subsequent releases of Encarta and these changes provide some interesting historical insights--including that if MS had had its way we'd all be writing web pages in RTF rather than HTML[1]. :D
You may ask, "What connection does this have to the Sony MMCD?".
Well, one of the storage formats used with early Encarta data is `.mvb` which is a format used by Microsoft Multimedia Viewer[2] (also known by multiple other names--none of which are any easier to web search :D ).
And, it turns out, "Multimedia Viewer could compile titles for Tandy Video Information System and other Modular Windows systems, as well as Sony Multimedia CD-ROM Player, a portable MS-DOS-based CD-ROM XA reader released in 1992."[2][3]
According to my research the tool "...includes software tools that simulate the look and feel of the Sony player titles on a PC" which is interesting in the context of the emulator for the Discman mentioned in the original post.
Anyway, that's the very short version of the rabbit hole--maybe in another five years I'll get around to writing up the rest...
Oh, sure, rpath/runpath shenanigans will work in some situations but then you'll be tempted to make such shenanigans work in all situations and then the madness will get you...
To save everyone a click here are the first two bullet points from Exhibit A:
* If an executable has `RPATH` (a.k.a. `DT_RPATH`) set but a shared library that is a (direct or indirect(?)) dependency of that executable has `RUNPATH` (a.k.a. `DT_RUNPATH`) set then the executable's `RPATH` is ignored!
* This means a shared library dependency can "force" loading of an incompatible [(for the executable)] dependency version in certain situations. [...]
Further nuances regarding LD_LIBRARY_PATH can be found in Exhibit B but I can feel the madness clawing at me again so will stop here. :)
I vaguely wondered if FreeHand would make an appearance in this thread. :)
Two features that come to mind as IIRC being unique (as compared to Illustrator) were multi-page documents and multiple page size multi-page documents. Ideal for the complete standard set of company branded print documents: business card, "With Compliments" slip, and letterhead. :D
Adobe's acquisition of Macromedia and subsequent killing of (the IMO superior) FreeHand contributed directly to my subsequent decision to avoid closed source application software--especially for creative tools--even if alternatives were "technically inferior".
(And, indeed, "creative tool killed/hampered for business reasons" is a story which has been repeated elsewhere multiple times in the quarter century[0] since.)
While Inkscape is still missing features compared to FreeHand it is however also still here many years later and is what I've used ever since when I need 2D vector design software. (Although I've also been keeping an eye on Graphite: https://graphite.rs)
> [...] waiting for one or more terminal emulators to get together and add some ridiculous new escape codes [...]
I'm definitely of the opinion[0] that we haven't yet reached the limits of the "terminal emulator" UX paradigm.
The past few years do seem to have seen a resurgence in terminal emulator innovation due in part to a combination of new languages, the prevalence of GPUs, and a realisation that many of the existing terminal emulators weren't interested in any innovation in certain directions.
I've particularly been interested in the possibilities provided by the Terminal Graphics Protocol (which I discuss more in the linked comment).
A couple of years ago I switched to WezTerm[2] due to a combination of its graphics support, implementation language (Rust) and that its main developer seems to be interested in a combination of both solid support for existing standards & opportunities for innovation.
WezTerm also provides opportunities for customisation both in terms of shell integrations and of the application itself[3].
> [...] new escape codes [...]
Also, on this aspect, it may not even be necessary to create new escape codes--recently I discovered the `terminfo(5)` man page actually makes a pretty interesting read[7], in part because it lists some existing escape codes that seem like they have potential for re-use/re-implementation in the current day's more graphic-based systems.
---- footnotes ----
[0] As I mentioned in a recent comment on a thread[1] here:
"Motivated by the thought that at the current point in time perhaps the 'essence' of a 'terminal' is its linear 'chronological' presentation of input/interaction/output history rather than its use of 'text'."
[3] While I'm definitely not a fan of the choice of Lua as the extension language, I have now at least hit my head against the wall[4] with it enough that I can actually get more complex custom functionality working.
[4] I've started to write up some of my Lua-related[5] notes & more general WezTerm[6] notes so hopefully it'll eventually be an easier road for others. :)
[7] As one does. :) It was a fascinating/amusing time capsule in terms(!) of mentions of weird hardware terminal quirks that at one time ("before my time") needed to be worked around; interesting escape code discoveries; and, the mention of a term I had not thought of for decades but was at one time of importance: NLQ! :D
Yeah, it would be nice if the financial backing behind Rhasspy/Piper led to improvements in espeak-ng too but based on my own development-related experience with the espeak-ng code base (related elsewhere in the thread) I suspect it would be significantly easier to extract the specific required text to phonemes functionality or (to a certain degree) reimplement it (or use a different project as a base[3]) than to more closely/fully integrate changes with espeak-ng itself[4]. :/
It seems Piper currently abstracts its phonemize-related functionality with a library[0] that currently makes use of a espeak-ng fork[1].
Unfortunately it also seems license-related issues may have an impact[2] on whether Piper continues to make use of espeak-ng.
For your specific example of handling 1984 as a year, my understanding is that espeak-ng can handle situations like that via parameters/configuration but in my experience there can be unexpected interactions between different configuration/API options[6].
[4] For example, as I note here[5] there's currently at least four different ways to access espeak-ng's phoneme-related functionality--and it seems that they all differ in their output, sometimes consistently and other times dependent on configuration (e.g. audio output mode, spoken punctuation) and probably also input. :/
It's been mentioned elsewhere in the comments but espeak-ng has historically prioritized accessibility use cases which is a domain where "quality" doesn't necessarily correlate with "naturalness" (e.g. there is a preference for clarity at high words-per-minute rates of speech where the speech doesn't sound "natural" but is still understandable, for people who have acclimatized to it through daily use, at least :) ).
As I've learned over time (and other people in these comments have clarified) it turns out that evaluating "quality" of Text To Speech is somewhat dependent on the domain in which the audio output is being used (obviously with overlaps), broadly:
The qualities of the generated speech which are favoured may differ significantly between the two domains, e.g. AIUI non-accessibility focused TTS often prioritises "realism" & "naturalness" while more accessibility focussed TTS often prioritizes clarity at high words-per-minute speech rates (which often sounds distinctly non-"realistic").
And, AIUI espeak-ng has historically been more focused on the accessibility domain.
FYI re: Mimic 3: the main developer Michael Hansen (a.k.a synesthesiam) (who also previously developed Larynx TTS) now develops Piper TTS (https://github.com/rhasspy/piper) which is essentially a "successor" to the earlier projects.
IIUC ongoing development of Piper TTS is now financially supported by the recently announced Open Home Foundation (which is great news as IMO synesthesiam has almost single-handed revolutionized the quality level--in terms of naturalness/realism--of FLOSS TTS over the past few years and it would be a real loss if financial considerations stalled continued development): https://www.openhomefoundation.org/projects/ (Ok, on re-reading OHF is more generally funding development of Rhasspy of which Piper TTS is one component.)
Background on the "trust metric" implemented on the site: https://web.archive.org/web/20160304000542/https://advogato....
Apparently my account on the site is/was now more than a quarter of a century old... Gonna try to avoid thinking on that too deeply. :D
There's been a non-zero number of occasions since that time where I've observed situations that mirror the trust-based challenges Advogato sought to solve.
It is perhaps telling that as prescient as Raph's work on trust metrics was he later moved on to the notoriously challenging realm of font rendering--presumably because it seemed more tractable. :D