Sunday I built a playlist from it. It took about forty minutes.

This is the post about why that number is already too low, and also possibly too high.

The Ritual

There is a specific kind of concert listening that happens in the days after a show. You go home, you look up the setlist — setlist.fm is the canonical archive, maintained with an almost academic precision by people who care — and you build a playlist from it in whatever streaming app you use. Then you play it through, in order, and what comes back is not just the music but the spatial memory of the room, the sound mix, the moment the lights dropped for that particular song.

I have been doing this for years. It is a ritual, and like most rituals, part of its meaning is in the doing. The forty minutes of searching song by song, the occasional discovery that a deep cut is on Apple Music in one version but not another, the fiddling with live versus studio — that friction is not purely annoying. It is part of the processing.

And yet. The pile of unprocessed setlists sits in a folder. Shows I attended and never got around to. Setlists I meant to build into playlists and didn’t, because the forty minutes were not available that week, and then the moment passed. The ritual unrealised is just a list of song titles.

This is the dilemma, and it is not entirely trivial.

Why This Is Harder Than It Should Be

The setlist.fm API is excellent. It gives you structured data: artist, venue, date, song titles in order, with notations for encores, covers, and dropped songs. What it does not give you is streaming IDs. The song title is a string; the Apple Music track is an object with a catalog ID, a duration, multiple versions, regional availability, and the possibility of not existing at all in the catalog of your country.

The matching problem — connecting a string like “Change (In the House of Flies)” to the correct Apple Music track, filtered for the right album version, ignoring the live recordings you did not ask for — is not hard, but it is fiddly. You can get 80% of a setlist matched automatically without much effort. The remaining 20% are the covers, the deep cuts, the songs with subtitles in parentheses that differ between the setlist record and the catalog metadata.

Spotify has a fairly rich ecosystem of community tools for exactly this workflow, because Spotify’s API is permissive and well-documented and the auth flow is reasonable for third-party developers. Apple Music is harder. The MusicKit framework is real and capable, but the authentication requires managing a private key and JWT tokens signed with developer credentials — not the OAuth dance most developers are used to. The result is that the setlist → Apple Music pipeline is significantly underbuilt compared to the Spotify equivalent.

This is partly why I built setlist-to-playlist as a PWA rather than reaching for an existing tool.

How It Works

The app is a Progressive Web App — installable, mobile-friendly, works as a small tool you open on your phone in the taxi home from a show — built on Next.js with a monorepo structure managed by pnpm and Turbo. The architecture is in three phases:

Import. You paste a setlist.fm URL or ID. The app queries setlist.fm through a server-side proxy — the API key lives on the server and never touches the client — and returns the structured setlist data: songs in order, with metadata about covers, medleys, and notes.

Preview and matching. The core package runs a matching algorithm against the Apple Music catalog, using the MusicKit JS API for browser-based catalog search. For each song title, it searches Apple Music and presents the best candidate, giving you the chance to confirm or swap before anything is written. This is the step where the 20% problem is addressed manually — the app handles the obvious cases automatically and surfaces the ambiguous ones for human judgement.

Export. Once you are happy with the track list, the app creates a playlist in your Apple Music library. MusicKit handles the authentication in-browser; the backend generates the JWT tokens using credentials from Apple Developer, signing with the private key server-side so it stays off the client.

The whole thing is local-first in the sense that matters: the Apple Music authentication is between your browser and Apple, and no playlist data or listening history is stored by the app. The only thing the server touches is the API key proxying and the JWT generation.

The Actual Experience

After the Deftones show: opened the app on the phone, pasted the setlist.fm URL, had the playlist in Apple Music in about four minutes. Three tracks needed manual confirmation — two because of live-versus-studio ambiguity, one because a cover required a search adjustment, the kind of edge case where the name setlist.fm records differs from what appears in regional streaming catalogs.

Four minutes instead of forty. Mission accomplished.

And yet.

I noticed, processing the setlist that quickly, that something was missing. Not the music — the music was all there, in order, correct. What was missing was the time spent inside the setlist. The forty minutes of handling each song is also forty minutes of thinking about each song, of remembering where in the set it fell, of deciding which album version you want to hear. The automation removed the friction and also removed the processing.

I am not sure this is a problem. It is probably more accurate to say that it is a trade-off, and that what trade-off you want depends on what you are doing with the ritual. If the backlog is the problem — the pile of unprocessed shows — the automation solves it cleanly. If the processing itself is the point, you probably should not automate it, and the tool is there for when you want it.

That is the correct relationship to automation, I think. Not “this should always be automated” or “this should never be automated”, but “here is a tool that removes the mechanical part; use it when the mechanical part is not the point”.

A Note on the Tech Stack

For the interested: Next.js 15 with App Router, pnpm workspaces with Turbo for the monorepo, MusicKit JS for Apple Music integration, setlist.fm REST API. The JWT for Apple Music uses the jose library for token signing. The matching logic lives in a standalone packages/core module, which makes it testable in isolation and reusable if anyone wants to port this to a different frontend or a CLI.

The repo is at github.com/sebastianspicker/setlist-to-playlist. PRs welcome, particularly around the matching heuristics — that is the part where there is the most room for improvement.

The Deftones were exceptional, for the record. The Westfalenhalle was loud in the way that only a concrete hall that size can be loud, which is to say: correctly loud.

The playlist is good. I am glad it took four minutes and not forty.

I am also glad I know what I gave up.

Last week Microsoft confirmed, in response to reporting by TechCrunch and others, that it had handed BitLocker recovery keys for three laptops to the FBI following a valid court order. The underlying case was a fraud investigation in Guam. The laptops were encrypted with BitLocker — the full-disk encryption built into Windows, which many institutions and individuals rely on as their primary protection against unauthorised data access.

The mechanism is simple and was not widely known. When you set up a modern Windows device and sign in with a Microsoft account, BitLocker automatically uploads your recovery key to Microsoft’s cloud. No prominent notification. No opt-in. The key sits there, associated with your account, accessible to Microsoft. When a US court issues a lawful order, Microsoft complies. Redmond confirmed this is policy, not an exception.

Bruce Schneier’s response was characteristically direct: “The lesson here is that if you have access to keys, eventually law enforcement is going to come.” Jennifer Granick at the ACLU called remote key storage in this configuration “quite dangerous,” particularly given that the same mechanism is available to any government that can issue a Microsoft-compatible legal order — not only the US Department of Justice.

That last point is the one European institutions should be reading carefully.

Why This Is a European Problem

The CLOUD Act — the US Clarifying Lawful Overseas Use of Data Act, passed in 2018 — allows US law enforcement to compel US-based companies to produce data held on servers anywhere in the world. If your university stores its BitLocker recovery keys in a Microsoft account, and Microsoft is a US company, the geographic location of the servers those keys sit on does not limit a US court’s reach. The keys are in Virginia, legally, wherever the hardware is.

This is not speculation. It is the explicit structure of US digital law. The European Court of Justice has repeatedly ruled that certain US surveillance frameworks are incompatible with GDPR — the invalidation of Privacy Shield in Schrems II (2020) being the most prominent example. But court rulings about data transfer frameworks do not automatically change the operational reality for an institution whose laptops are running Windows with default settings.

European universities hold exactly the kinds of data that make this a real rather than a theoretical concern:

• Research data: medical studies, clinical trials, interviews with human subjects, social science datasets — all subject to strict ethical and legal protections
• Student records: academic performance, personal circumstances, disciplinary proceedings
• HR data: employment contracts, salary records, health information, union activity — particularly sensitive under German and EU labour law
• Correspondence and draft documents: research in progress, grant applications, peer review material

If the disk holding any of this is encrypted with BitLocker, and the recovery key has been uploaded to a Microsoft account by default, the encryption provides less protection than it appears to. The key is accessible to a foreign state with a court order. That state is not party to GDPR.

The Structural Problem

The BitLocker story is one instance of a larger pattern. It is not that Microsoft behaved unusually or maliciously — it complied with a lawful order in its home jurisdiction, as it is legally required to do. The problem is structural: when an institution depends on a closed-source, US-headquartered platform for its critical infrastructure, the institution has delegated control over its own data to an entity whose legal obligations lie elsewhere.

This applies beyond encryption. It applies to email (Exchange Online, Outlook), document storage (SharePoint, OneDrive), communication (Teams), identity management (Azure Active Directory), and any service that runs through a Microsoft account or Azure tenant. For each of these: the data is subject to Microsoft’s terms, and Microsoft is subject to US law.

The same argument applies, with different specifics, to Google Workspace and any other US-headquartered platform. The issue is not that these companies are bad actors. It is that their legal accountability and the legal accountability of European public institutions point in incompatible directions, and the institutions mostly have not noticed.

What Sovereign Software Looks Like

The alternative is not paranoia and air-gapped servers. It is a coherent strategy for institutional digital infrastructure that is based on software the institution controls.

In Germany, this conversation has a name and a project. OpenDesk — developed under the aegis of the federal and state governments — is a stack of open-source tools (Nextcloud, Collabora Online, Matrix/ Element, Jitsi, Keycloak, Open-Xchange) assembled into an integrated workspace alternative to Microsoft 365. The Souveräner Arbeitsplatz (sovereign workspace) concept behind it is exactly what the BitLocker story illustrates: if the software is open, the keys stay in your institution, and no foreign court can reach them via a warrant served on a US company.

Several German states and federal agencies have been piloting OpenDesk. The city of Munich’s earlier experiment with Linux (LiMux) and its eventual rollback to Windows is the cautionary tale here — not because open source failed, but because the transition was not supported seriously enough over time, and the incumbent vendor’s lobbying was. The BitLocker story is a reminder of what is at stake in that political negotiation.

The FSFE’s “Public Money? Public Code!” campaign has articulated the principle cleanly: software developed with public funding should be released as open-source software. The argument is not only about freedom as an abstract value. It is about the practical consequence of being locked into a proprietary platform: your institution loses the ability to audit what the software does, to modify it to meet your requirements, to host it where your data protection law applies, and to switch providers without losing access to your own data.

What I Do, and Why

I work at a publicly funded institution. The software I build for institutional contexts — campus infrastructure, workforce management, archival systems, alert systems — is public.

Not because I am ideologically committed to open source as a movement, but because the alternative is incoherent. If I build tooling for a university with public funds and keep it closed, I have produced a private asset with public money, duplicated by every institution that builds the same thing independently, inspectable by nobody, and ultimately dependent on my continued willingness to maintain it or hand it over. None of those outcomes serve the institutions I am building for.

Here is what that looks like in practice:

zammad-ticket-archiver — automated archival of Zammad support tickets as cryptographically signed PDFs, with RFC 3161 timestamps for non-repudiation. Built for institutions that need legally defensible audit trails of their helpdesk operations. The signing infrastructure is self-hosted; no external party holds the keys.

alarm-broker — a silent panic alarm broker for campus facilities. Receives emergency triggers from hardware devices (Yealink keys), distributes notifications via Zammad, SMS, and Signal, with acknowledgment tracking and escalation scheduling. Runs locally, logs to self-hosted PostgreSQL; no external dependency for the alarm path.

campus-app-kit — a React Native / Expo starter for university mobile applications, with a pluggable Node.js backend designed for institutional data sources (room booking, events, schedules). The architecture separates institution-specific connectors (which institutions keep private) from the shared foundation (which is public). Any university can take it and build on it without starting from scratch.

cueq — an integrated workforce management system for German universities under TV-L (the collective agreement for public sector employees in the German states). Handles time recording, shift planning, absence management, payroll export, and GDPR-compliant audit trails. Built around NestJS and Next.js, with a PostgreSQL backend and Honeywell terminal integration. The HR data stays on the institution’s own infrastructure.

These are all boring. They are not research contributions; they are plumbing. But plumbing is what holds institutions together, and the question of who controls the plumbing — and under whose legal jurisdiction — is exactly the question the BitLocker story makes visible.

The Principle

Public money, public code. If an institution funded by public money develops software for its own operations, that software should be released under an open licence, inspectable, forkable, and deployable by any institution with the same needs.

The corollary: institutions funded by public money should prefer software that is itself openly licensed, auditable, and deployable on infrastructure the institution controls. Not as a blanket ban on proprietary tools where they are genuinely the best option, but as a starting presumption that shifts the burden of justification.

The BitLocker story is not a story about Microsoft doing something wrong. It is a story about the logical consequence of a procurement decision that was made without asking “and what happens when a US court sends a subpoena?” That question was available in 2018 when the CLOUD Act passed, in 2020 when Schrems II was decided, and before both. It is still available now, for every institution that has not yet asked it.

The FSFE “Public Money? Public Code!” campaign is at publiccode.eu. The OpenDesk project is at opendesk.de. The original TechCrunch reporting on the BitLocker handover is at techcrunch.com.

I agree with the impulse. I am less sure about what the phrase actually asks of us, or what it assumes is possible. This post is my attempt to think through that question — and to document a small project that emerged from it.

A Personal Starting Point

I am on the spectrum. I was diagnosed in adulthood, which is not unusual, and the diagnosis explained a great deal about a life spent finding some things effortless and others bewildering.

Code is easy. The internal structure of a problem, the satisfaction of a clean abstraction, the deep rabbit holes that open when a concept catches my attention and refuses to let go — that is the natural medium. Hyperfocus is not a metaphor for me; it is literally how I spend a Tuesday afternoon. I have written entire systems because I could not stop.

Emotions are harder. Not absent — that is a misconception I will address in a moment — but differently structured. Reading a room is work. Social cues that seem to operate as obvious background noise for most people arrive for me as data that requires conscious decoding. The reverse appears to be true for most neurotypical people: emotional processing runs in the background, effortlessly; formal abstraction requires deliberate effort.

Neither is better. They are different cognitive architectures, and both come with costs.

I raise this not to centre myself, but because it is relevant to the question the post is actually about. I spent years navigating a social world that was not built for how I process it. That experience sits close to the experience of people with mental illness — not the same, but adjacent. And it made me think hard about what “understanding” across neurological difference actually means.

Mental Illness Is Still a Grey Zone

The progress on mental health stigma over the past decade is real. People talk about therapy more openly than they did. Burnout is acknowledged at work. The language of mental health has entered mainstream use — sometimes usefully, sometimes in ways that dilute clinical concepts into lifestyle descriptors. Anxiety is now a brand attribute. Trauma is a metaphor for mild inconvenience. This is a problem, but it is a second-order problem; the first-order problem — that serious mental illness is still heavily stigmatised, underfunded, and misunderstood — is the one that matters more.

Corrigan and Watson [1] documented what the stigma research consistently shows: people with mental illness face two compounding problems. The first is public stigma [3] — the prejudice of others, leading to discrimination in employment, housing, relationships. The second is self-stigma — the internalised application of those same prejudices to oneself. The second is often worse. It is the mechanism by which stigma becomes a barrier to seeking help, creating the feedback loop that keeps serious mental illness invisible precisely because the people experiencing it have been taught that it is shameful.

The phrase “make it visible” is a response to this dynamic. If mental illness is visible — discussed, depicted, normalised — the argument goes that stigma decreases. There is evidence for this. Contact-based interventions, where people without mental illness interact with people who have it, consistently outperform education-only approaches [2]. The visibility of real people matters more than information campaigns.

But there is a difference between visibility and understanding.

What Visibility Actually Achieves

When we say “make it visible”, we usually mean one of several different things, which are worth separating.

Normalisation means that a condition becomes part of accepted human variation rather than a mark of failure or danger. This is achievable through visibility and is genuinely important. Knowing that a colleague takes antidepressants, or that a public figure manages bipolar disorder, reduces the sense of aberration. It does not require the observer to understand the experience — only to register that it exists and is survivable.

Representation means that people with a condition see themselves reflected in culture, media, and institutions. This matters for the affected person; it is about recognition, not about inducing empathy in the non-affected.

Empathy is the hardest and most frequently over-promised goal. It is what the simulation approaches aim for: put a neurotypical person in a room with distorted audio and flickering visuals and tell them this is what psychosis sounds like. Does it work?

The honest answer from the research is: somewhat, temporarily, and with significant caveats.

The Empathy Gap

Let me be direct about something. A person who has never experienced severe depression cannot know what it is. Not in the way that a person who has experienced it knows it. This is not a failure of empathy or imagination; it is a structural fact about how knowledge of mental states works.

Philosophers call this the problem of other minds. We have no direct access to another person’s experience. We infer it, imperfectly, by analogy to our own. For experiences that have no analogue in our own history, inference breaks down. You can read every clinical description of dissociation ever written and still not know what dissociation is, because the knowledge that matters is not propositional — it is not a set of facts — but experiential.

This is the gap that simulation approaches try to bridge, and it is genuinely unbridgeable. What simulation can do is something weaker but not worthless: it can create an affective response, a discomfort, a disruption of the observer’s normal processing, that functions as a rough proxy signal. Not “now you know what it is like”, but “now you have a small, incomplete, distorted approximation of some dimension of the experience”.

The risk is misrepresentation. Schizophrenia simulations have been criticised — fairly — for reducing a complex condition to its most dramatic phenomenological features (auditory hallucinations, paranoia) while omitting the cognitive, relational, and longitudinal aspects that define how people actually live with the condition. A five-minute visual experience of “what depression feels like” that emphasises darkness and slow motion tells you almost nothing about the specific exhaustion of getting through a Tuesday morning, or the way time warps over months.

So: you cannot truly understand what you have not experienced. But you can try to approximate something, and approximation, done honestly and with appropriate epistemic humility, is better than nothing.

Metaphor as a Communication Tool

There is a long tradition of using metaphor and art to communicate internal states that resist direct description. This is not a bug; it is a feature of how language handles subjective experience.

The poet uses metaphor because “my heart is heavy” is not literally true but captures something that “I am experiencing low mood” does not. The musician uses dissonance and rhythm to structure emotional experience in the listener. The visual artist uses colour and texture to evoke states rather than depict them. None of these are representations in the scientific sense — they do not accurately model the referent — but they create a kind of resonance that purely descriptive language cannot.

Mental health communication has increasingly moved in this direction. The vocabulary of “emotional weight”, “spiralling”, “crashing”, “the fog” — these are metaphors that have become clinical shorthand precisely because they communicate something essential that clinical terms do not. When someone says “I couldn’t get out of bed”, they are not describing paralysis; they are describing a particular quality of anhedonia and executive dysfunction that no diagnostic manual entry captures as well.

This is the space where a project like inner-echo operates.

Inner Echo: The Idea

inner-echo is a browser-based audiovisual experiment. It takes a webcam feed and applies condition-specific visual and audio effects that function as metaphorical overlays on the user’s own image. The output is not a simulation of a mental health condition in any clinical sense. It is an attempt to construct a visual and auditory language for internal states, using the user’s own presence as the anchor.

The technical architecture is deliberately minimal: React, WebGL/Canvas for video processing, optional WebAudio. Everything runs in the browser, client-side, with no backend. No data leaves the device. This is not incidental — privacy is load-bearing for a project that deals with sensitive self-reflection. Safe Mode and an emergency stop function are built in.

The condition-profile system supports three modes:

• Preset mode: a single-condition metaphorical composition — one set of effects mapped to one cluster of experiences
• Multimorbid mode: weighted stacking of multiple condition profiles, acknowledging that most people with mental health conditions do not have one thing
• Symptom-first mode: dimension-level control, letting the user build from individual symptom representations rather than diagnostic labels

The last of these is, I think, the most honest design choice. Diagnostic categories are administrative conveniences as much as they are natural kinds. Two people with the same diagnosis can have radically different experiences. Structuring the system around dimensions of experience rather than labels is both clinically more accurate and communicatively more flexible.

What It Is Not

Being clear about limitations is not false modesty; it is the only way this kind of project retains its integrity.

inner-echo is not a simulation of any condition in the sense of accurately modelling its phenomenology. It does not claim to show you “what depression is like”. It offers metaphorical approximations of some dimensions of some experiences, and it does so using effects that are legible to the observer — visual distortion, audio modification, altered feedback — that bear a designed but non-literal relationship to the internal states they are meant to evoke.

It is not a diagnostic tool. It is not a therapeutic intervention. It is not a substitute for any clinical process.

What it might be is a starting point for a conversation. Something a person experiencing a condition could use to gesture toward an aspect of their experience. Something a person without that experience could encounter with enough curiosity to ask a better question than they would have otherwise.

That is a modest claim. I think modest claims are appropriate here.

Why This, Why Now

Mental health awareness has become a genre. The awareness campaigns, the celebrity disclosures, the workplace wellness programmes — these are real goods, and I do not want to be cynical about them. But the communication problem has not been solved. The words exist. The willingness to use them, in many contexts, exists. What is still missing is a language for the texture of experience that the words point to but do not reach.

I find myself better able to build something than to explain it in words. That is probably a spectrum thing. inner-echo is an attempt to build toward a language that I do not fully have — for my own internal experience, and for the experiences of people navigating conditions quite different from mine.

The gap cannot be closed. But the attempt to reach across it is worth making, and worth being honest about.

References

[1] Corrigan, P.W. & Watson, A.C. (2002). Understanding the impact of stigma on people with mental illness. World Psychiatry, 1(1), 16–20.

[2] Corrigan, P.W., Morris, S.B., Michaels, P.J., Rafacz, J.D. & Rüsch, N. (2012). Challenging the public stigma of mental illness: A meta-analysis of outcome studies. Psychiatric Services, 63(10), 963–973.

[3] Goffman, E. (1963). Stigma: Notes on the Management of Spoiled Identity. Prentice-Hall.

inner-echo repository: https://github.com/sebastianspicker/inner-echo

The short answer is that YouTube does not work fine, for reasons that matter specifically to universities. The longer answer is what this post is about.

What Is Wrong with YouTube

YouTube is the world’s dominant video platform. It is free to use, globally available, handles any file size, transcodes automatically, and comes with an audience of two billion logged-in users. For individual creators who want reach, it is genuinely hard to beat.

For universities it fails in at least three important ways.

Data protection. When you upload a lecture or a concert recording to YouTube, the content, the metadata, and the viewing behaviour of your students go to Google’s servers — which are predominantly in the United States. Under the GDPR, transferring personal data to third countries requires either an adequacy decision, standard contractual clauses with additional safeguards, or explicit informed consent. After the Schrems II ruling (Court of Justice of the EU, 2020), the adequacy of US-based data transfers became legally contested in a way that makes institutional YouTube use genuinely difficult for European universities. Using it for anything with identifiable students — which includes most teaching content — is a compliance problem.

Platform logic. YouTube is designed to maximise watch time. Its recommendation algorithm is not neutral. It will recommend whatever comes after your lecture, and what comes after your lecture is not under your control. For educational content — especially sensitive material, or content that should remain in a defined pedagogical context — this is a real problem. The platform is not indifferent to what is hosted on it; it shapes how it is consumed.

Institutional fragility. YouTube is free until it isn’t. Platform terms change; monetisation policies change; content is demonetised or removed based on automated systems with imperfect appeal mechanisms. Building institutional infrastructure on a free commercial service is a bet that the commercial incentives of that service will remain aligned with your needs. That bet has a poor historical record.

None of this means that individual instructors should never use YouTube. It means that universities should not make YouTube their default institutional solution.

educast.nrw: A Cooperative Model

educast.nrw is a project of the Digitale Hochschule NRW — a cooperative of North Rhine-Westphalian universities building shared digital infrastructure. The concept is a state-wide video service, run by universities for universities, for the recording, processing, management, and distribution of video content in teaching and research. The platforms calls itself “Hochschul-YouTube”, which is both accurate and slightly underselling what makes it different.

The HfMT Köln participates as a user institution, which is where I come in as the IT contact for setting it up on our end.

The technical foundation is Opencast, an open-source video management system developed by a consortium of universities. This matters: the software is auditable, the development direction is set by the institutions that use it rather than by advertising revenue, and the infrastructure runs on German servers that are explicitly GDPR-compliant. Licenses on uploaded content are freely choosable — CC-BY-SA is an option, which means the university’s teaching materials can be open access if that is what the instructor wants.

What It Can Do

The feature set covers the actual use cases of a university, not the use cases of a content creator trying to build a following.

Recording. The Opencast Studio browser app records in three modes: screen only, camera only, or screen and camera simultaneously as a synchronised multi-stream. That last option — Presentation and Presenter as separate streams, played back with the viewer switching focus between them, or as picture-in-picture — is the format that works for a lecture. You get the slides and the speaker in the same video, but the viewer can choose which to focus on. That flexibility is not something you get from a simple screen recording uploaded to YouTube.

Multi-perspective video. For a music university this is the feature that changes things. A concert or a masterclass is not well-served by a single camera angle. The platform supports simultaneous recording from two camera perspectives — a wide shot and a detail shot, say, or a front view and a hands view for a piano performance. The viewer can switch between them in playback, or the institution can set a default presentation. This is infrastructure that makes the teaching use of concert recordings actually feasible, not just technically possible.

Formats. Video up to 4K with adaptive bitrate streaming (the player adjusts automatically to the viewer’s connection), audio up to broadcast quality (48kHz/16-bit, exceeding CD’s 44.1kHz), with FLAC at up to 96kHz/24-bit in development. No file size limit. These specifications matter for music. A piano recording compressed to whatever YouTube decides to do with it is not the same as an uncompromised audio stream. The difference is audible.

ILIAS integration. This is the practical hinge. Video that lives in a separate platform is video that students may or may not find. Video embedded directly in the ILIAS course page, in the learning module, at the point in the curriculum where it is relevant — that is video that is part of the course rather than adjacent to it. The integration between educast.nrw and ILIAS is direct: upload to the video platform, embed in ILIAS on pages, in learning modules, or as standalone video objects, all from within ILIAS.

Access rights. The granularity here is what distinguishes it from any public platform. Each video can be set to: public (anyone on the internet), institution-wide (anyone logged in at the university), course-wide (only enrolled students in a specific course), individual (specific named people), or private (only the uploader). A graduation concert might be public. A practice session for student feedback might be course-only. A recording made for an individual student’s reflection might be shared only with that student and their teacher. These are all normal use cases in a music university; they all require different settings; the platform handles all of them.

Use Cases in a Music University

The general university use case — lecture recording, video tutorial, self-study module — applies at HfMT as much as anywhere. But a music and dance university has some specific ones.

Concert recordings. HfMT Köln runs performances at both its Cologne and Wuppertal sites. Recording these and making them available to students, faculty, and selectively to the public used to mean someone had to manage files, find hosting, deal with YouTube’s automated copyright detection flagging student performances of copyrighted repertoire, and explain to students why their graduation concert had been muted by an algorithm. The controlled platform makes all of this manageable.

Stage presence as a reflective tool. Watching yourself perform is a standard part of performance training. It is uncomfortable, useful, and until recently required either dedicated recording equipment or the ad-hoc use of a phone propped against something. A proper recording infrastructure with controlled access — the student sees the video, their teacher sees the video, nobody else does — changes the pedagogical viability of this approach. The barrier to actually using video feedback in practice teaching drops substantially.

Theory and practice. This is the institutional argument I made in the presentation and stand by: video infrastructure that works for a lecture also works for a concert. The same system that stores the introduction to music theory also stores the masterclass by a visiting artist. This is not incidental — it is the point of a shared infrastructure. You do not need to choose a platform for academic content and a different one for performance content. The platform works for both.

The Argument Behind the Argument

There is a broader principle at work here that extends beyond video platforms. Public universities are funded by public money. The infrastructure they build with that money — software, platforms, data, content — should be under their control, governed by their values, and ideally available to other public institutions. The commercial platform model inverts this: you get free hosting in exchange for your data, your students’ attention, and your institutional dependence.

educast.nrw is an example of what the alternative looks like in practice: a cooperative of public institutions building shared infrastructure on open-source software, governed collectively, with data on European servers under European law. It is not perfect — the setup overhead is real, the user experience does not match YouTube’s, and the feature roadmap (automatic subtitling, H5P support, livestreaming, annotation tools) is still catching up to what commercial platforms have had for years. But the model is right.

The question of who owns the video infrastructure of a university is the same question as who owns its email, its learning management system, its student data. The answer should be: the university, operating under law, answerable to its students and to the public that funds it.

The slides from the Tag der Lehre 2022 presentation are available on request. For educast.nrw setup at HfMT Köln, contact the IT department.

Links

• educast.nrw
• Opencast
• Opencast Studio
• Tobira Videoportal
• opencast-ilias plugin (GitHub)

Changelog

• 2025-08-18: Corrected the capitalisation of “OpenCast” to “Opencast” throughout (matching the project’s official spelling on opencast.org).