If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/stakira/OpenUtau shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 1d ago
• 21+ active contributors
• Distributed ownership (top contributor 25% of recent commits)
• MIT licensed
• CI configured
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live stakira/OpenUtau repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/stakira/OpenUtau.

What it runs against: a local clone of stakira/OpenUtau — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in stakira/OpenUtau | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of stakira/OpenUtau. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/stakira/OpenUtau.git
#   cd OpenUtau
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of stakira/OpenUtau and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "stakira/OpenUtau(\\.git)?\\b" \\
  && ok "origin remote is stakira/OpenUtau" \\
  || miss "origin remote is not stakira/OpenUtau (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "OpenUtau.Core/Classic/VoiceBank.cs" \\
  && ok "OpenUtau.Core/Classic/VoiceBank.cs" \\
  || miss "missing critical file: OpenUtau.Core/Classic/VoiceBank.cs"
test -f "OpenUtau.Core/Classic/ClassicRenderer.cs" \\
  && ok "OpenUtau.Core/Classic/ClassicRenderer.cs" \\
  || miss "missing critical file: OpenUtau.Core/Classic/ClassicRenderer.cs"
test -f "OpenUtau.Core/Api/Phonemizer.cs" \\
  && ok "OpenUtau.Core/Api/Phonemizer.cs" \\
  || miss "missing critical file: OpenUtau.Core/Api/Phonemizer.cs"
test -f "OpenUtau.Core/DiffSinger/DiffSingerRenderer.cs" \\
  && ok "OpenUtau.Core/DiffSinger/DiffSingerRenderer.cs" \\
  || miss "missing critical file: OpenUtau.Core/DiffSinger/DiffSingerRenderer.cs"
test -f "OpenUtau.Core/Commands/UCommand.cs" \\
  && ok "OpenUtau.Core/Commands/UCommand.cs" \\
  || miss "missing critical file: OpenUtau.Core/Commands/UCommand.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/stakira/OpenUtau"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

OpenUtau is a free, open-source singing synthesis editor designed as a successor to UTAU, enabling musicians to create synthesized vocals by composing notes with phoneme-level control. It processes audio through multiple analysis pipelines (Crepe pitch detection, RMVPE, MIDI extraction) and renders synthesized singing via resamplers and phonemizers, supporting both classic UTAU-compatible workflows and modern neural approaches. Monolithic C# desktop app: OpenUtau.Core contains the synthesis engine split into Analysis/ (pitch detection, MIDI extraction), Api/ (phonemizer/G2P plugin interfaces), Audio/ (output abstraction), and Classic/ (UTAU format rendering). WPF/Avalonia UI in separate assemblies. Build system uses Starlark (Bazel) for cross-platform distribution.

Vocaloid/UTAU enthusiasts and singing voice synthesis hobbyists who want a modern, cross-platform alternative to the aging UTAU software; also music producers and plugin developers building custom phonemizers (see OpenUtau.Core/Api/) to support new languages or synthesis methods.

Actively developed and production-ready: multi-platform releases (Windows x64/x86, macOS, Linux), established CI/CD via GitHub Actions (build.yml, pr-test.yml), large C# codebase (5.7MB), active community on Discord, and structured issue templates. The project maintains backward compatibility with UTAU voicebanks while adding modern features.

Low-to-moderate risk: single primary maintainer (stakira), but stable release cadence and responsive issue triage visible. Dependencies on external tools (resamplers, phonemizers) are managed via separate plugin architecture (OpenUtau.Core/Api/PhonemizerInstaller.cs), reducing version-lock risk. Watch for breaking changes in the phonemizer API as the project evolves.

Active development on audio analysis (pitch detection improvements via Crepe/RMVPE), phonemizer plugin infrastructure (G2pDictionary refactoring), and multilingual support (Crowdin integration visible in workflows). Recent work suggests focus on accuracy and extensibility rather than feature-creep.

git clone https://github.com/stakira/OpenUtau.git
cd OpenUtau
# Requires .NET SDK (check .csproj files for version)
dotnet build OpenUtau.sln
dotnet run --project OpenUtau

Note: Check GitHub workflows (build.yml) for exact SDK version and any native dependencies (audio libraries).

Daily commands: After dotnet build OpenUtau.sln: dotnet run --project OpenUtau launches the desktop app. See .github/workflows/build.yml for full build matrix (Windows, macOS, Linux native builds use platform-specific toolchains).

• OpenUtau.Core/Classic/VoiceBank.cs — Core voicebank data structure and loader—all singing synthesis depends on correctly parsing and loading voicebank configurations and audio samples.
• OpenUtau.Core/Classic/ClassicRenderer.cs — Primary audio rendering engine for UTAU-style synthesis—handles the pipeline from notes to rendered audio output.
• OpenUtau.Core/Api/Phonemizer.cs — Abstract phonemizer interface that all language backends (Chinese, English, DiffSinger, etc.) must implement—central abstraction for phoneme conversion.
• OpenUtau.Core/DiffSinger/DiffSingerRenderer.cs — Neural renderer backend using DiffSinger models—represents the modern synthesis alternative to classic UTAU rendering.
• OpenUtau.Core/Commands/UCommand.cs — Base command class implementing undo/redo pattern for all editor operations—essential for maintaining project state consistency.
• OpenUtau.Core/Classic/PluginRunner.cs — Plugin execution framework for external resampler and wavtool tools—bridges OpenUtau to legacy UTAU plugin ecosystem.
• OpenUtau.Core/Analysis/Crepe/Crepe.cs — Pitch detection engine using CREPE neural network—critical for accurate fundamental frequency extraction from audio input.

Add a New Language Phonemizer

1. Create a new class inheriting from Phonemizer abstract base (OpenUtau.Core/Api/Phonemizer.cs)
2. Implement ConvertPhonemes() and GetDictionary() methods for your language (OpenUtau.Core/DiffSinger/DiffSingerBasePhonemizer.cs (reference implementation))
3. Register your phonemizer in PhonemizerFactory using the plugin discovery pattern (OpenUtau.Core/Api/PhonemizerFactory.cs)
4. Add G2P dictionary fallbacks if needed for robustness (OpenUtau.Core/Api/G2pFallbacks.cs)
5. Test with DiffSinger or Classic rendering by setting it as the active phonemizer in project config

Add Support for a New Synthesis Backend

1. Create a new renderer class (e.g., NewSynthRenderer.cs) implementing the rendering pipeline (OpenUtau.Core/Classic/ClassicRenderer.cs (pattern reference))
2. Implement pitch curve interpolation and variance processing if needed (OpenUtau.Core/DiffSinger/DiffSingerPitch.cs (reference for modern variance handling))
3. Integrate into the project rendering dispatch logic (likely in Commands/ProjectCommands.cs) (OpenUtau.Core/Commands/ProjectCommands.cs)
4. Add configuration schema if your backend needs tune-able parameters (OpenUtau.Core/DiffSinger/DiffSingerConfig.cs (reference))

Add a New Pitch Detection Algorithm

1. Create analyzer class in OpenUtau.Core/Analysis/ directory (OpenUtau.Core/Analysis/Crepe/Crepe.cs (ONNX-based reference))
2. Implement pitch extraction returning float[] frequency contour and confidence scores (OpenUtau.Core/Analysis/Some.cs (interface reference))
3. Integrate into UI note transcription workflow, typically called before NoteCommands.cs processing
4. Load any required model files into OpenUtau.Core/Analysis/Resources.resx if using neural models

• C# / .NET — Cross-platform GUI framework (Avalonia), strong ecosystem for desktop apps, good IDE tooling; mature language for a long-lived synthesis project.
• ONNX Runtime — Unified inference backend for neural models (CREPE, DiffSinger, vocoder); hardware acceleration (CPU/GPU/NPU) without vendor lock-in.
• Plugin/Process Isolation (ExeResampler, ExeWavtool) — Backward compatibility with 20+ years of UTAU plugin ecosystem; sandboxing of untrusted external tools; minimal breaking changes for users.
• miniaudio — Lightweight, single-header audio I/O library; cross-platform (Windows, macOS, Linux); low latency for real-time playback.

• Support both classic UTAU rendering (plugin-based) and neural DiffSinger rendering

  • Why: Two distinct synthesis communities with different workflows; retaining classic support maximizes user base and asset reuse.
  • Consequence: Dual code paths, complex renderer dispatch logic, and testing burden; added complexity in phonemization/variance handling for each path.

• External plugin execution vs. in-process synthesis

  • Why: Preserves ecosystem of existing UTAU tools (resampler, wavtool); allows users to mix-and-match legacy plugins.
  • Consequence: Process overhead, serialization/deserialization cost (~100–500ms per note render), difficult to debug cross-process failures, platform-specific path resolution.

• Dictionary-based fallback phonemization (G2pDictionary) rather than pure rule-based

  • Why: Fast, deterministic, language-agnostic baseline; reduces dependency on heavy NLP models for every language.
  • Consequence: Limited handling of rare words, homographs, or neologisms; requires manual dictionary curation per language.

• Undo/redo as first-class command pattern (UCommand) rather than state snapshots

  • Why: Fine-grained redo, low memory overhead, enables selective und
  • Consequence: undefined

1. Phonemizer plugins expect specific working directory structure; check PhonemizerRunner.cs for subprocess invocation details. 2) Crepe.cs bundles a 24MB tiny.onnx model; ensure ONNX Runtime is installed (may require separate NuGet package depending on OS). 3) Audio output uses MiniAudio abstraction layer—platform-specific natives may be missing if built on unsupported OS. 4) G2P (grapheme-to-phoneme) pipeline chains multiple fallbacks (see G2pFallbacks.cs); test phonemizer integration with target language before assuming defaults work.

• ONNX (Open Neural Network Exchange) — Crepe.cs uses pre-trained ONNX models for pitch detection; understanding ONNX runtime inference is key to modifying or replacing the audio analysis pipeline
• Grapheme-to-Phoneme (G2P) conversion — Core to the synthesis pipeline; G2pDictionary.cs and G2pRemapper.cs convert text lyrics into phonetic sequences that resamplers use; essential for supporting new languages
• Pitch detection and frequency analysis — Crepe and Rmvpe implementations in Analysis/ extract fundamental frequency from audio; understanding pitch contours is critical for synthesis accuracy
• Plugin/extension architecture (IPhonемizer interface) — The phonemizer system uses interface-based polymorphism and subprocess isolation; understanding this pattern is essential for adding new synthesis backends without modifying core
• Resamplers and vocoding — ClassicRenderer.cs calls external resamplers (WORLD, SoundFont, etc.) to synthesize audio segments; understanding how OpenUtau bridges high-level phoneme sequences to low-level sample generation is crucial
• MIDI and DAW integration — MidiExtractor.cs and MIDI support throughout the codebase allow OpenUtau to import compositions from DAWs; relevant for workflow and file format compatibility
• Cross-platform UI abstraction (WPF/Avalonia) — UI layer uses platform-agnostic C# frameworks to maintain single codebase across Windows, macOS, Linux; understanding the abstraction is vital for UI contributions

• mmorise/World — Classic vocoder used as a resampler backend in OpenUtau; understanding WORLD is essential for modifying synthesis quality
• OpenSpeech-EGG/OpenUtau-Core — Fork/community fork exploring neural synthesis extensions; reference for how others extend the phonemizer API
• UTAU-Synth/UTAU — Original UTAU software (closed-source Windows-only); OpenUtau's format compatibility and inspiration source
• espeak-ng/espeak-ng — Multilingual phonemizer often wrapped as an OpenUtau plugin; example of how phonemizers integrate into the system
• pytorch/pytorch — Deep learning framework used by some community phonemizers (e.g., neural G2P models); relevant for understanding advanced plugin development

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for G2P (Grapheme-to-Phoneme) API and Phonemizer components

The OpenUtau.Core/Api directory contains critical phonemization logic (G2pDictionary.cs, G2pPack.cs, Phonemizer.cs, PhonemizerFactory.cs) but there are no visible test files in the repository structure. Given that phonemization is core to singing synthesis accuracy across multiple languages, comprehensive unit tests would catch regressions early and help new contributors understand the API contract. This is especially important for BaseChinesePhonemizer.cs and the G2pRemapper.cs which handle language-specific transformations.

• [ ] Create OpenUtau.Tests project alongside OpenUtau.Core if it doesn't exist
• [ ] Add tests for G2pDictionary.cs covering dictionary loading, lookup, and fallback behavior
• [ ] Add tests for Phonemizer.cs and PhonemizerFactory.cs covering instantiation and phoneme generation
• [ ] Add tests for BaseChinesePhonemizer.cs covering tone mark handling and romanization
• [ ] Add test for G2pRemapper.cs covering phoneme remapping edge cases

Add GitHub Actions workflow for plugin/phonemizer compatibility testing

The repo has build.yml, pr-test.yml, and release-cleanup.yml workflows, but no dedicated workflow for testing plugin compatibility. Given the complex plugin system (PluginLoader.cs, IPlugin.cs, ExeInstaller.cs, ExeResampler.cs, ExeWavtool.cs), adding a workflow that validates classic UTAU plugin loading and execution on Windows would catch breakages early. This is particularly valuable since the plugin ecosystem bridges OpenUtau with legacy UTAU tools.

• [ ] Create .github/workflows/plugin-compatibility.yml workflow file
• [ ] Configure workflow to run on PR and commit to main branch
• [ ] Add steps to download/prepare test UTAU plugins (resampler, wavtool examples)
• [ ] Add test job that validates PluginLoader.cs can discover and load plugins
• [ ] Add validation for ExeResampler.cs and ExeWavtool.cs execution paths
• [ ] Document expected plugin structure in OpenUtau.Core/Classic/README.md

Add missing documentation for Analysis module (AudioSlicer, Crepe, Rmvpe, MidiExtractor)

The OpenUtau.Core/Analysis directory contains sophisticated pitch detection and audio analysis tools (Crepe.cs with ONNX model, Rmvpe.cs, AudioSlicer.cs, MidiExtractor.cs, Game.cs) but there is no README or API documentation explaining how these components work together or how to use them programmatically. Adding comprehensive documentation here would help contributors understand the audio processing pipeline and make it easier to extend pitch detection algorithms.

• [ ] Create OpenUtau.Core/Analysis/README.md documenting the analysis pipeline
• [ ] Document Crepe.cs ONNX model usage, inputs/outputs, and accuracy characteristics
• [ ] Document Rmvpe.cs as an alternative pitch detector with comparison to Crepe
• [ ] Document AudioSlicer.cs algorithm and parameters for splitting audio into notes
• [ ] Document MidiExtractor.cs for converting pitch contours back to MIDI
• [ ] Add code examples showing how to use these components for batch pitch analysis

• Add unit tests for OpenUtau.Core/Analysis/AudioSlicer.cs—currently no test coverage visible; good for learning audio windowing and edge cases without UI complexity.
• Expand G2pDictionary.cs to support loading external dictionary files via config; current implementation is hardcoded; straightforward file I/O improvement.
• Document the phonemizer plugin API (OpenUtau.Core/Api/README.md exists but is sparse) with a runnable example showing how to wrap a new G2P system like g2p-en; would help grow the plugin ecosystem.

OpenUtau shows a moderate security posture with several concerns primarily related to external plugin execution, package installation, and embedded binary resources. The main security risks stem from the architecture's support for loading external plugins and voice banks without comprehensive sandboxing or verification mechanisms. While there are no obvious hardcoded credentials or injection vulnerabilities visible in the file structure, the ability to execute external code and install untrusted packages represents a significant attack surface. The embedded ONNX models should have integrity verification. Dependency audit results are unavailable. Implementing plugin sandboxing, package signature verification, and enhanced input validation would substantially improve the security posture.

• Medium · Embedded ONNX Model Files — OpenUtau.Core/Analysis/Crepe/tiny.onnx, OpenUtau.Core/Classic/Data/mel.onnx. The codebase includes embedded ONNX model files (tiny.onnx, mel.onnx) as binary resources. These files are opaque and difficult to audit for malicious modifications. There is a risk of supply chain attacks if these models were compromised during development or dependency updates. Fix: Implement integrity verification (SHA256 checksums) for critical model files. Document the provenance and source of these models. Consider downloading models at runtime from verified sources rather than embedding them. Implement signature verification for critical dependencies.
• Medium · External Plugin Execution without Sandboxing — OpenUtau.Core/Classic/PluginLoader.cs, OpenUtau.Core/Classic/PluginRunner.cs, OpenUtau.Core/Classic/ExeResampler.cs, OpenUtau.Core/Classic/ExeWavtool.cs. The codebase loads and executes external plugins (PluginLoader.cs, PluginRunner.cs, ExeResampler.cs, ExeWavtool.cs) without apparent sandboxing. This allows arbitrary code execution through malicious or compromised plugins, particularly from user-provided voice banks or custom resampler/wavtool executables. Fix: Implement plugin sandboxing or capability restrictions. Require explicit user consent before loading external plugins. Implement digital signature verification for trusted plugins. Add audit logging for plugin execution. Document security implications to users.
• Medium · Unrestricted Voice Bank/Package Installation — OpenUtau.Core/Classic/VoicebankInstaller.cs, OpenUtau.Core/Classic/VoicebankLoader.cs. VoicebankInstaller.cs and related code allow installation of voice banks from potentially untrusted sources. Without proper validation, malicious voice bank packages could contain harmful files or exploits. Fix: Implement package signature verification. Validate package structure and contents before extraction. Implement size limits for packages. Use restricted extraction paths. Implement package scanning/validation. Document trusted sources for voice banks.
• Low · Potential Path Traversal in File Operations — OpenUtau.Core/Classic/VoicebankFiles.cs, OpenUtau.Core/Classic/VoicebankLoader.cs. VoicebankFiles.cs and various file handling operations may be vulnerable to path traversal attacks if user-controlled input is not properly sanitized when constructing file paths. Fix: Implement strict path validation using Path.GetFullPath() and verify paths are within expected directories. Use whitelist approaches for allowed file paths. Never construct paths by string concatenation. Use built-in path validation methods.
• Low · Missing Dependency Information — Package dependencies - not analyzed. No package dependency file (csproj, package.json, requirements.txt) was provided in the analysis. Cannot assess for known vulnerable dependency versions. Fix: Provide .csproj files and run dependency audits using tools like dotnet list package --vulnerable and OWASP Dependency-Check. Enable automatic dependency updates and security advisories.
• Low · Lack of Input Validation in Configuration Files — OpenUtau.Core/Classic/VoicebankConfig.cs, OpenUtau.Core/Classic/Ini.cs. VoicebankConfig.cs and Ini.cs parse configuration files without apparent strict validation. Malformed or malicious config files could cause unexpected behavior or errors. Fix: Implement strict schema validation for configuration files. Use strongly-typed configuration parsing. Implement bounds checking and type validation for all parsed values. Add error handling for malformed configurations.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.