1db6d066c0
- Body SolidWorks v1 → 02_PRODUITS_PHYSIQUES/Microphone/Conception/ - Studio Mic KiCAD (DIYPerks) → 02_PRODUITS_PHYSIQUES/R&D_References/DIY/ - cleanup_ports.sh → 04_INFRA_DEPLOIEMENT/ - mockup_jeu_ux → 11_RECHERCHE_&_LAB/ - Printables → 12_DOCUMENTATION/Imprimables/ - Screenshots, ideas, one.html → _BROUILLON/ - all-talas (23Go) → 13_ARCHIVES/ - Supprimé all-talas.zip (20Go doublon), lock files LibreOffice - Nettoyé .gitignore - Remote → Forgejo (10.0.20.105:3000) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
639 lines
20 KiB
HTML
639 lines
20 KiB
HTML
|
||
<!DOCTYPE html>
|
||
<html>
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<title>Intercalaire 11 - RECHERCHE & LAB</title>
|
||
<style>
|
||
body { font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif; line-height: 1.6; max-width: 900px; margin: 0 auto; padding: 20px; color: #333; }
|
||
h1 { border-bottom: 2px solid #2c3e50; padding-bottom: 10px; color: #2c3e50; font-size: 2.5em; }
|
||
h2 { color: #34495e; margin-top: 1.5em; border-bottom: 1px solid #eee; padding-bottom: 5px; }
|
||
h3 { color: #7f8c8d; }
|
||
pre { background: #f8f9fa; padding: 15px; border-radius: 5px; overflow-x: auto; font-size: 0.9em; border: 1px solid #e9ecef; }
|
||
code { font-family: Consolas, Monaco, monospace; background: #f8f9fa; padding: 2px 4px; border-radius: 3px; }
|
||
table { border-collapse: collapse; width: 100%; margin-bottom: 1.5em; }
|
||
th, td { border: 1px solid #dee2e6; padding: 10px; text-align: left; }
|
||
th { background-color: #f8f9fa; font-weight: bold; }
|
||
.doc-header { background-color: #ecf0f1; padding: 15px; border-radius: 5px; margin-bottom: 20px; margin-top: 40px; border-left: 5px solid #3498db; }
|
||
.doc-header h2 { margin: 0; border: none; padding: 0; color: #2980b9; }
|
||
.doc-path { font-family: monospace; font-size: 0.9em; color: #7f8c8d; }
|
||
|
||
@media print {
|
||
body { max-width: 100%; padding: 0; margin: 1cm; font-size: 11pt; }
|
||
.page-break { page-break-before: always; }
|
||
pre, code { white-space: pre-wrap; word-wrap: break-word; font-size: 10pt; border: none; background: transparent; }
|
||
a { text-decoration: none; color: black; }
|
||
h1 { font-size: 24pt; }
|
||
h2 { font-size: 18pt; }
|
||
h3 { font-size: 14pt; }
|
||
.doc-header { border: 1px solid #ccc; background-color: transparent; }
|
||
}
|
||
</style>
|
||
</head>
|
||
<body>
|
||
<h1>Intercalaire 11 : RECHERCHE & LAB</h1>
|
||
<p><em>Généré le 4 Avril 2026 - Projet Talas</em></p>
|
||
<hr>
|
||
<div class='page-break'></div>
|
||
|
||
<div class='doc-header'>
|
||
<h2>📄 README.md</h2>
|
||
<div class='doc-path'>Chemin: 11_RECHERCHE_&_LAB/Concepts_Futurs/README.md</div>
|
||
</div>
|
||
|
||
<h1>Concepts Futurs – Talas de demain</h1>
|
||
<p>Ce dossier documente les <strong>idées d'évolution radicale ou long-terme</strong> pour Talas, indépendamment de la roadmap actuelle. Il agit comme un incubateur conceptuel pour la vision du projet à 3–5–10 ans.</p>
|
||
<h2>Objectifs :</h2>
|
||
<ul>
|
||
<li>Imaginer de nouveaux usages, modèles ou technologies pour Talas.</li>
|
||
<li>Poser les bases de futurs produits, services, ou partenariats.</li>
|
||
<li>Aligner les ambitions à long terme avec les retours du présent.</li>
|
||
</ul>
|
||
<h2>Contenu recommandé :</h2>
|
||
<ul>
|
||
<li><code>Talas_V2/</code> : extension du modèle (DAO, API publique, marketplace)</li>
|
||
<li><code>modèles_distribués/</code> : P2P, offline, local-first</li>
|
||
<li><code>modularité_totale/</code> : hardware, firmware, plugins</li>
|
||
<li><code>études/</code> : rapports d’usage, articles prospectifs</li>
|
||
<li><code>specs_sauvages.md</code> : idées en vrac, sans contrainte</li>
|
||
</ul>
|
||
<blockquote>
|
||
<p>Ce dossier n’est pas destiné à produire immédiatement, mais à rêver stratégiquement.</p>
|
||
</blockquote>
|
||
<div class='page-break'></div>
|
||
|
||
<div class='doc-header'>
|
||
<h2>📄 README.md</h2>
|
||
<div class='doc-path'>Chemin: 11_RECHERCHE_&_LAB/IA_&_Audio_LLM/README.md</div>
|
||
</div>
|
||
|
||
<h1>Intelligence Artificielle & Audio</h1>
|
||
<p>Ce dossier regroupe les <strong>tests d’intégration de modèles IA/LLM</strong> dans les outils Talas, notamment autour du traitement audio, de la classification, de l’assistance créative ou du remix.</p>
|
||
<h2>Objectifs :</h2>
|
||
<ul>
|
||
<li>Évaluer les possibilités d’IA pour aider les artistes Talas.</li>
|
||
<li>Prototyper des assistants de tri, transcription, taggage, ou composition.</li>
|
||
<li>Tester l’intégration de LLMs open-source et d’audio transformers.</li>
|
||
</ul>
|
||
<h2>Contenu recommandé :</h2>
|
||
<ul>
|
||
<li><code>tests/</code> : whisper, musicgen, bark, stable audio</li>
|
||
<li><code>playground.ipynb</code> : notebooks d’essais</li>
|
||
<li><code>idées_usecases.md</code> : ex. assistant mix, tags auto, plugin IA</li>
|
||
<li><code>retours_artistes.md</code> : réactions à l’utilisation de l’IA</li>
|
||
</ul>
|
||
<blockquote>
|
||
<p>Le traitement IA ne doit pas aliéner le processus créatif, mais l’augmenter. Ce dossier permet d’explorer cette frontière.</p>
|
||
</blockquote>
|
||
<div class='page-break'></div>
|
||
|
||
<div class='doc-header'>
|
||
<h2>📄 README.md</h2>
|
||
<div class='doc-path'>Chemin: 11_RECHERCHE_&_LAB/README.md</div>
|
||
</div>
|
||
|
||
<h1>11_RECHERCHE_&_LAB – Exploration & Innovation</h1>
|
||
<p>Ce dossier accueille les expérimentations technologiques ou créatives autour du projet.</p>
|
||
<h2>Objectifs</h2>
|
||
<ul>
|
||
<li>Prototyper sans contrainte de production immédiate.</li>
|
||
<li>Explorer des pistes techniques innovantes (streaming, AI audio, modularité).</li>
|
||
<li>Préparer de futurs produits ou extensions.</li>
|
||
</ul>
|
||
<h2>Contenu attendu</h2>
|
||
<ul>
|
||
<li><code>UX_Explorations/</code> : interfaces inédites, voix, IA assistée.</li>
|
||
<li><code>Techno_Rust_Streaming/</code> : WebRTC, codecs, audio distant.</li>
|
||
<li><code>IA_&_Audio_LLM/</code> : tests de classification, transcripteurs, assistants IA.</li>
|
||
<li><code>Concepts_Futurs/</code> : Talas V2, collaboration décentralisée, DAO.</li>
|
||
</ul>
|
||
<h2>Responsable</h2>
|
||
<p>Tech lead + équipe innovation + artistes collaborateurs</p>
|
||
<h2>Connexions transversales</h2>
|
||
<ul>
|
||
<li><code>03_APPS_&_SERVICES/</code> (modules expérimentaux Rust)</li>
|
||
<li><code>06_COMMUNAUTE_ECOSYSTEME/</code> (tests avec early adopters)</li>
|
||
</ul>
|
||
<div class='page-break'></div>
|
||
|
||
<div class='doc-header'>
|
||
<h2>📄 README.md</h2>
|
||
<div class='doc-path'>Chemin: 11_RECHERCHE_&_LAB/Techno_Rust_Streaming/README.md</div>
|
||
</div>
|
||
|
||
<h1>Techno Rust & Streaming Audio</h1>
|
||
<p>Ce dossier contient les <strong>expérimentations techniques en Rust</strong> liées au traitement audio temps réel, au streaming, à l’encodage et à la performance des flux.</p>
|
||
<h2>Objectifs :</h2>
|
||
<ul>
|
||
<li>Prototyper un moteur Rust hautement performant pour AudioGridder ou Talas Live.</li>
|
||
<li>Comparer les performances des codecs (Opus, FLAC, AAC…).</li>
|
||
<li>Intégrer WebRTC, UDP, ou gRPC dans les modules backend.</li>
|
||
</ul>
|
||
<h2>Contenu recommandé :</h2>
|
||
<ul>
|
||
<li><code>codecs/</code> : benchs comparatifs Opus vs FLAC</li>
|
||
<li><code>webRTC/</code> : client minimal, démonstrateurs</li>
|
||
<li><code>module_audio_engine/</code> : prototype pipeline audio Rust</li>
|
||
<li><code>observabilité/</code> : latence, gigue, pertes, métriques</li>
|
||
</ul>
|
||
<blockquote>
|
||
<p>Ces travaux pourront alimenter <code>03_APPS_&_SERVICES/Personal/AudioGridder_Client</code>.</p>
|
||
</blockquote>
|
||
<div class='page-break'></div>
|
||
|
||
<div class='doc-header'>
|
||
<h2>📄 RECHERCHE_PROTOCOLES_AUDIO.md</h2>
|
||
<div class='doc-path'>Chemin: 11_RECHERCHE_&_LAB/Techno_Rust_Streaming/RECHERCHE_PROTOCOLES_AUDIO.md</div>
|
||
</div>
|
||
|
||
<h1>Recherche Technique — Protocoles Audio et Streaming</h1>
|
||
<blockquote>
|
||
<p>Comparaison des codecs, protocoles de streaming et architectures pour Veza.
|
||
Informe les choix techniques du stream server Rust (Axum).
|
||
Date : 27 mars 2026.</p>
|
||
</blockquote>
|
||
<hr />
|
||
<h2>1. Codecs audio — comparaison</h2>
|
||
<h3>Codecs pertinents pour le streaming musical</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>Codec</th>
|
||
<th>Type</th>
|
||
<th>Bitrate typique</th>
|
||
<th>Latence</th>
|
||
<th>Qualité perçue</th>
|
||
<th>Licence</th>
|
||
<th>Usage Veza</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><strong>Opus</strong></td>
|
||
<td>Lossy</td>
|
||
<td>64-256 kbps</td>
|
||
<td>5-66 ms</td>
|
||
<td>Excellente (transparent à 128 kbps)</td>
|
||
<td>BSD (libre)</td>
|
||
<td>WebSocket temps réel</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>AAC-LC</strong></td>
|
||
<td>Lossy</td>
|
||
<td>128-256 kbps</td>
|
||
<td>~20 ms</td>
|
||
<td>Très bonne</td>
|
||
<td>Brevets (gratuit pour decode)</td>
|
||
<td>HLS segments</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>MP3</strong></td>
|
||
<td>Lossy</td>
|
||
<td>128-320 kbps</td>
|
||
<td>~50 ms</td>
|
||
<td>Bonne</td>
|
||
<td>Brevets expirés (libre)</td>
|
||
<td>Téléchargement, fallback</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>FLAC</strong></td>
|
||
<td>Lossless</td>
|
||
<td>700-1400 kbps</td>
|
||
<td>Variable</td>
|
||
<td>Parfaite (bit-perfect)</td>
|
||
<td>Libre</td>
|
||
<td>Stockage source, download premium</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>Vorbis</strong></td>
|
||
<td>Lossy</td>
|
||
<td>64-320 kbps</td>
|
||
<td>~20 ms</td>
|
||
<td>Bonne</td>
|
||
<td>BSD (libre)</td>
|
||
<td>Alternative Opus (containers Ogg)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>WAV</strong></td>
|
||
<td>Non compressé</td>
|
||
<td>1411 kbps (16-bit/44.1)</td>
|
||
<td>0</td>
|
||
<td>Parfaite</td>
|
||
<td>Libre</td>
|
||
<td>Upload source</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<h3>Recommandation pour Veza</h3>
|
||
<p><strong>Architecture multi-codec :</strong></p>
|
||
<pre><code>Upload (WAV/FLAC source)
|
||
│
|
||
▼
|
||
Transcoding (FFmpeg via stream server Rust)
|
||
│
|
||
├── HLS adaptatif : AAC-LC à 64/128/256 kbps (compatibilité maximale)
|
||
├── WebSocket : Opus à 128 kbps (qualité optimale à bas bitrate)
|
||
└── Téléchargement : FLAC (lossless) ou MP3 320 (compatibilité)
|
||
</code></pre>
|
||
<p><strong>Pourquoi Opus pour le WebSocket :</strong>
|
||
- Meilleur rapport qualité/bitrate de tous les codecs lossy
|
||
- Transparent à 128 kbps (indiscernable du lossless pour la musique)
|
||
- Latence extrêmement basse (5 ms possible, 20 ms typique)
|
||
- 100% libre (BSD license) — pas de royalties
|
||
- Supporté nativement par tous les navigateurs modernes (WebRTC)
|
||
- Adaptatif : peut varier le bitrate dynamiquement selon le réseau</p>
|
||
<p><strong>Pourquoi AAC-LC pour le HLS :</strong>
|
||
- Standard HLS d'Apple (compatibilité maximale iOS/Safari)
|
||
- Meilleur support hardware decode que Opus sur les appareils mobiles
|
||
- Qualité acceptable à 128 kbps pour le streaming
|
||
- Brevets mais decode gratuit dans les navigateurs</p>
|
||
<hr />
|
||
<h2>2. Protocoles de streaming — comparaison</h2>
|
||
<h3>Protocoles pertinents</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>Protocole</th>
|
||
<th>Latence</th>
|
||
<th>Adaptatif</th>
|
||
<th>Support navigateur</th>
|
||
<th>Complexité serveur</th>
|
||
<th>Usage</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><strong>HLS</strong> (HTTP Live Streaming)</td>
|
||
<td>6-30s</td>
|
||
<td>Oui (multi-bitrate)</td>
|
||
<td>Universel (natif Safari, HLS.js partout)</td>
|
||
<td>Moyen</td>
|
||
<td>Streaming audio standard</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>DASH</strong> (MPEG-DASH)</td>
|
||
<td>6-30s</td>
|
||
<td>Oui (multi-bitrate)</td>
|
||
<td>Via dash.js (pas natif)</td>
|
||
<td>Moyen</td>
|
||
<td>Alternative ouverte à HLS</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>LL-HLS</strong> (Low Latency HLS)</td>
|
||
<td>1-3s</td>
|
||
<td>Oui</td>
|
||
<td>Safari natif, HLS.js partiel</td>
|
||
<td>Élevé</td>
|
||
<td>Live streaming</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>WebSocket</strong></td>
|
||
<td><100ms</td>
|
||
<td>Manuel</td>
|
||
<td>Universel</td>
|
||
<td>Faible-Moyen</td>
|
||
<td>Temps réel (co-écoute, sync)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>WebRTC</strong></td>
|
||
<td><100ms</td>
|
||
<td>Oui (native)</td>
|
||
<td>Universel</td>
|
||
<td>Élevé (TURN/STUN)</td>
|
||
<td>P2P audio (co-écoute future)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>Icecast/Shoutcast</strong></td>
|
||
<td>2-10s</td>
|
||
<td>Non</td>
|
||
<td>Via lecteur audio</td>
|
||
<td>Faible</td>
|
||
<td>Radio/stream continu</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<h3>Architecture retenue par Veza (actuelle)</h3>
|
||
<pre><code>Cas 1 : Lecture standard (playlist, bibliothèque)
|
||
→ HLS adaptatif (AAC-LC, segments .ts, playlist .m3u8)
|
||
→ Multi-bitrate : 64 / 128 / 256 kbps
|
||
→ Client : HLS.js (ou natif Safari)
|
||
|
||
Cas 2 : Co-écoute synchronisée
|
||
→ WebSocket (Opus)
|
||
→ Protocole de sync personnalisé (play/pause/seek/heartbeat)
|
||
→ Latence cible : <200ms entre participants
|
||
|
||
Cas 3 : Live streaming (futur)
|
||
→ RTMP ingest (OBS → Nginx-RTMP)
|
||
→ Transcoding → HLS (LL-HLS si latence critique)
|
||
→ Distribution via stream server Rust
|
||
</code></pre>
|
||
<h3>Pourquoi HLS et pas DASH</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>Critère</th>
|
||
<th>HLS</th>
|
||
<th>DASH</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Support iOS/Safari</td>
|
||
<td>Natif</td>
|
||
<td>Via JS uniquement</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Support Android/Chrome</td>
|
||
<td>Via HLS.js</td>
|
||
<td>Via dash.js</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Écosystème</td>
|
||
<td>Dominant (Apple, FFmpeg)</td>
|
||
<td>Plus ouvert mais moins adopté</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Complexité</td>
|
||
<td>Standard, bien documenté</td>
|
||
<td>Standard mais fragmenté</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Outils</td>
|
||
<td>FFmpeg supporte nativement</td>
|
||
<td>FFmpeg supporte nativement</td>
|
||
</tr>
|
||
<tr>
|
||
<td>CDN compatible</td>
|
||
<td>Tous</td>
|
||
<td>Tous</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p>HLS est le choix pragmatique : support natif Safari + HLS.js partout ailleurs = couverture 100%.
|
||
DASH n'apporte pas d'avantage justifiant la complexité supplémentaire.</p>
|
||
<hr />
|
||
<h2>3. HLS adaptatif — détails techniques</h2>
|
||
<h3>Structure des fichiers</h3>
|
||
<pre><code>hls/{track_id}/
|
||
├── master.m3u8 # Playlist maître (liste les qualités)
|
||
├── low/
|
||
│ ├── playlist.m3u8 # 64 kbps AAC-LC
|
||
│ └── segment_XXX.ts # Segments de 6 secondes
|
||
├── medium/
|
||
│ ├── playlist.m3u8 # 128 kbps AAC-LC
|
||
│ └── segment_XXX.ts
|
||
├── high/
|
||
│ ├── playlist.m3u8 # 256 kbps AAC-LC
|
||
│ └── segment_XXX.ts
|
||
└── lossless/ # (optionnel, pour abonnés premium)
|
||
├── playlist.m3u8 # FLAC
|
||
└── segment_XXX.ts
|
||
</code></pre>
|
||
<h3>Sélection adaptative du bitrate</h3>
|
||
<p>Le stream server Rust implémente une sélection adaptative :</p>
|
||
<ol>
|
||
<li><strong>Démarrage</strong> : commence en <code>medium</code> (128 kbps)</li>
|
||
<li><strong>Monitoring</strong> : mesure la bande passante disponible (vitesse de download des segments)</li>
|
||
<li><strong>Montée</strong> : si bande passante > 2x bitrate actuel pendant 3 segments → passer en <code>high</code></li>
|
||
<li><strong>Descente</strong> : si buffer < 3 segments → passer en <code>low</code> immédiatement</li>
|
||
<li><strong>Stabilisation</strong> : ne pas osciller — hysteresis de 2 segments</li>
|
||
</ol>
|
||
<h3>Paramètres de transcoding FFmpeg</h3>
|
||
<pre><code class="language-bash"># Qualité basse (64 kbps)
|
||
ffmpeg -i input.wav -c:a aac -b:a 64k -ar 44100 -ac 2 \
|
||
-hls_time 6 -hls_list_size 0 -hls_segment_filename 'low/segment_%03d.ts' \
|
||
low/playlist.m3u8
|
||
|
||
# Qualité moyenne (128 kbps)
|
||
ffmpeg -i input.wav -c:a aac -b:a 128k -ar 44100 -ac 2 \
|
||
-hls_time 6 -hls_list_size 0 -hls_segment_filename 'medium/segment_%03d.ts' \
|
||
medium/playlist.m3u8
|
||
|
||
# Qualité haute (256 kbps)
|
||
ffmpeg -i input.wav -c:a aac -b:a 256k -ar 48000 -ac 2 \
|
||
-hls_time 6 -hls_list_size 0 -hls_segment_filename 'high/segment_%03d.ts' \
|
||
high/playlist.m3u8
|
||
</code></pre>
|
||
<hr />
|
||
<h2>4. Latence et co-écoute</h2>
|
||
<h3>Budget de latence pour la co-écoute</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>Étape</th>
|
||
<th>Latence</th>
|
||
<th>Cumulé</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Encodage Opus (client A)</td>
|
||
<td>20 ms</td>
|
||
<td>20 ms</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Transmission WebSocket</td>
|
||
<td>10-50 ms</td>
|
||
<td>30-70 ms</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Décodage Opus (client B)</td>
|
||
<td>20 ms</td>
|
||
<td>50-90 ms</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Buffer de jitter</td>
|
||
<td>50 ms</td>
|
||
<td>100-140 ms</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>Total</strong></td>
|
||
<td></td>
|
||
<td><strong>100-140 ms</strong></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p>La co-écoute synchronisée est viable avec un décalage perceptible de <200 ms. Au-delà, les participants perçoivent un décalage gênant.</p>
|
||
<h3>Protocole de synchronisation (implémenté)</h3>
|
||
<p>Le stream server utilise un protocole de sync via WebSocket :</p>
|
||
<pre><code>Host envoie position → Serveur redistribue → Participants ajustent
|
||
↓
|
||
Tolérance : ±200ms
|
||
Si écart > 200ms : resync forcé
|
||
Heartbeat : 30s
|
||
</code></pre>
|
||
<hr />
|
||
<h2>5. Stockage et bande passante</h2>
|
||
<h3>Estimation par piste (4 minutes, stéréo, 44.1 kHz)</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>Format</th>
|
||
<th>Taille</th>
|
||
<th>Bande passante nécessaire</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>WAV source (24-bit)</td>
|
||
<td>~63 Mo</td>
|
||
<td>N/A (upload seul)</td>
|
||
</tr>
|
||
<tr>
|
||
<td>FLAC</td>
|
||
<td>~25 Mo</td>
|
||
<td>700-1400 kbps</td>
|
||
</tr>
|
||
<tr>
|
||
<td>HLS high (256 kbps AAC)</td>
|
||
<td>~7.5 Mo</td>
|
||
<td>256 kbps</td>
|
||
</tr>
|
||
<tr>
|
||
<td>HLS medium (128 kbps AAC)</td>
|
||
<td>~3.8 Mo</td>
|
||
<td>128 kbps</td>
|
||
</tr>
|
||
<tr>
|
||
<td>HLS low (64 kbps AAC)</td>
|
||
<td>~1.9 Mo</td>
|
||
<td>64 kbps</td>
|
||
</tr>
|
||
<tr>
|
||
<td><strong>Total par piste (tous formats)</strong></td>
|
||
<td><strong>~101 Mo</strong></td>
|
||
<td></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<h3>Capacité serveur (R720 avec fibre 1 Gbps)</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>Métrique</th>
|
||
<th>Valeur</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Bande passante disponible</td>
|
||
<td>1 Gbps ≈ 125 Mo/s</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Flux simultanés (128 kbps)</td>
|
||
<td><strong>~7 800</strong></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Flux simultanés (256 kbps)</td>
|
||
<td><strong>~3 900</strong></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Stockage MinIO (HDD 1.8 To, ZFS mirror = 900 Go utile)</td>
|
||
<td>~9 000 pistes</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p>Pour les premiers 200-500 utilisateurs actifs, la capacité est largement suffisante.</p>
|
||
<hr />
|
||
<h2>6. Formats d'upload acceptés</h2>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th>Format</th>
|
||
<th>Extension</th>
|
||
<th>Priorité</th>
|
||
<th>Notes</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>WAV</td>
|
||
<td>.wav</td>
|
||
<td>Principal</td>
|
||
<td>Non compressé, meilleure source pour transcoding</td>
|
||
</tr>
|
||
<tr>
|
||
<td>FLAC</td>
|
||
<td>.flac</td>
|
||
<td>Principal</td>
|
||
<td>Lossless, économise la bande passante upload</td>
|
||
</tr>
|
||
<tr>
|
||
<td>AIFF</td>
|
||
<td>.aiff</td>
|
||
<td>Secondaire</td>
|
||
<td>Équivalent WAV (Apple)</td>
|
||
</tr>
|
||
<tr>
|
||
<td>MP3</td>
|
||
<td>.mp3</td>
|
||
<td>Accepté</td>
|
||
<td>Lossy — transcoding depuis lossy non idéal</td>
|
||
</tr>
|
||
<tr>
|
||
<td>OGG/Vorbis</td>
|
||
<td>.ogg</td>
|
||
<td>Accepté</td>
|
||
<td>Libre</td>
|
||
</tr>
|
||
<tr>
|
||
<td>AAC/M4A</td>
|
||
<td>.m4a, .aac</td>
|
||
<td>Accepté</td>
|
||
<td>Lossy</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
<p><strong>Recommandation à l'utilisateur</strong> : uploader en WAV ou FLAC pour la meilleure qualité de transcoding.</p>
|
||
<hr />
|
||
<h2>7. Pistes de recherche future</h2>
|
||
<h3>WebRTC pour la co-écoute P2P</h3>
|
||
<p>Avantage : réduirait la charge serveur (le stream passe directement entre participants).
|
||
Inconvénient : complexité (STUN/TURN), NAT traversal, incompatibilité derrière certains firewalls.
|
||
<strong>Verdict</strong> : pas pour le MVP. Le WebSocket centralisé est suffisant et plus fiable.</p>
|
||
<h3>Opus dans les segments HLS</h3>
|
||
<p>HLS supporte officiellement les segments audio en fragmented MP4 (fMP4) avec codec Opus depuis 2020.
|
||
Avantage : meilleure qualité à bas bitrate que AAC.
|
||
Inconvénient : support Safari limité (iOS 17+).
|
||
<strong>Verdict</strong> : à surveiller. Quand Safari ≥17 sera dominant (estimé 2027), migrer de AAC vers Opus dans HLS.</p>
|
||
<h3>Streaming lossless adaptatif (MQA / ALAC / FLAC over HLS)</h3>
|
||
<p>Pour un futur tier premium : streaming FLAC via segments HLS fMP4.
|
||
Apple Music et Tidal le font déjà.
|
||
Nécessite : bande passante client ≥1.5 Mbps, stockage serveur ×3.
|
||
<strong>Verdict</strong> : pertinent pour un tier payant futur. Pas prioritaire pour le lancement.</p>
|
||
<hr />
|
||
<h2>Voir aussi</h2>
|
||
<ul>
|
||
<li>[[03_APPS_&<em>SERVICES/APIs</em>&_Rust_Modules/SERVEUR_STREAMING_RUST]] — Architecture du stream server</li>
|
||
<li>[[03_APPS_&_SERVICES/ARCHITECTURE_VEZA]] — Architecture globale Veza</li>
|
||
<li>[[03_APPS_&_SERVICES/CONFIGURATION_ENVIRONNEMENT]] — Configuration des services</li>
|
||
<li>[[00_META/Glossaire/GLOSSAIRE_TALAS]] — Termes techniques (HLS, Opus, FFmpeg, etc.)</li>
|
||
</ul>
|
||
<div class='page-break'></div>
|
||
|
||
<div class='doc-header'>
|
||
<h2>📄 README.md</h2>
|
||
<div class='doc-path'>Chemin: 11_RECHERCHE_&_LAB/UX_Explorations/README.md</div>
|
||
</div>
|
||
|
||
<h1>UX Explorations – Interfaces Innovantes</h1>
|
||
<p>Ce dossier regroupe les <strong>expérimentations UX/UI</strong> autour de nouvelles manières d’interagir avec les outils Talas : interfaces vocales, génératives, immersives, tactiles ou alternatives.</p>
|
||
<h2>Objectifs :</h2>
|
||
<ul>
|
||
<li>Tester des interactions originales et inspirantes.</li>
|
||
<li>Explorer des modes de navigation adaptés aux artistes.</li>
|
||
<li>Réfléchir aux usages dans des contextes non standards (studio mobile, low tech…).</li>
|
||
</ul>
|
||
<h2>Contenu recommandé :</h2>
|
||
<ul>
|
||
<li><code>concepts_ui.md</code> : idées brutes, inspirations (music tech, art interactif…)</li>
|
||
<li><code>prototypes/</code> : interfaces Figma non conventionnelles</li>
|
||
<li><code>tests_utilisateurs/</code> : retours sur prototypes innovants</li>
|
||
<li><code>journal_exploration.md</code> : documentation itérative</li>
|
||
</ul>
|
||
<blockquote>
|
||
<p>Aucun livrable n’est attendu ici. C’est un champ libre d’essais créatifs, inspiré par les artistes eux-mêmes.</p>
|
||
</blockquote>
|
||
</body>
|
||
</html>
|