Standalone Karaoke recording SDK

1. Purpose and proposal approach

This document is daudio::dev’s final technical and commercial proposal for the standalone karaoke recording SDK. It confirms acceptance of StarManch’s aligned decisions of 30 October 2026, and locks the January 2027 scope, product behaviour, milestone fees, acceptance criteria, and remaining joint actions.

What follows is for planning and contractual alignment. Open items in §9 need a short written confirmation by the date stated for each. Scope or timeline changes must be recorded in writing, including impact on cost and milestone dates.

2. Executive decision summary

3. Confirmation of StarManch decisions

3.1 Backing-track playback

StarManch: Native SDK playback during recording.
daudio::dev: Accepted.

• The SDK will control backing-track playback, microphone capture, vocal monitoring, recording position, and synchronisation through one coordinated audio pipeline (miniaudio / platform M4A decoder as needed).
• The app provides the local backing-track file path and required output paths.
• The SDK exposes playback-position callbacks/APIs frequently enough for Flutter lyric and UI sync.
• Flutter may handle browsing, download management, and preview outside an active recording session.
• Supported MP3/WAV and M4A/AAC decoder formats, seek behaviour, pause/resume behaviour, and platform-specific limitations will be documented.

Reason: Native playback reduces timing drift and simplifies coordination for pause/resume under interruptions. Final behaviour will be validated on the agreed Android and iOS devices.

3.2 Final export formats

StarManch: M4A (AAC) and MP3 only. WAV not required.
daudio::dev: Accepted.

• M4A (AAC): primary recommended export.
• MP3: secondary for broader compatibility, playback, and sharing.
• WAV: not required for final export.
• Configurable bitrate and quality for both formats. Stereo output.
• While the mix is exporting, Flutter gets progress updates, a done event with the finished file path, or an error if export fails.
• Mixing and effects run in high-quality internal audio (float PCM). We encode to M4A or MP3 only at the final export step.
• Exact default settings and AAC bitrate finalised during Alpha after quality, file-size, and performance testing.

3.3 Reference melody data

StarManch: JSON primary. MIDI preferred if practical.
daudio::dev: Accepted.

• JSON schema: MIDI note number, start ms, duration ms, optional A4 (default 440 Hz).
• One lead-vocal melody line per song for initial scoring/correction.
• If MIDI is supported: agree vocal channel/track, tempo/timing interpretation, and supply method.
• LRC lyric timing files must not be assumed to contain note-level pitch data.
• Draft JSON melody schema, validation rules, file-size expectations, and a sample melody file are in Appendix C so StarManch can prepare per-song melody data before Alpha. MIDI conventions, if used, will be agreed separately so they do not delay January.

Important dependency: Melody-based scoring and melody-guided correction cannot operate reliably for a song unless corresponding reference melody data is available, correctly timed, and validated. StarManch’s content pipeline supplies or creates that data per supported song.

3.4 Noise reduction

StarManch: Basic optional gate / light NR in January.
daudio::dev: Accepted as a January add-on (€600).

• January acceptance for NR = available, switchable, and documented limits on the agreed devices — not studio-grade NR.
• Intended to reduce low-level room hiss on quieter passages. Soft singing and monitoring latency impact are documented as known limits, not a zero-artefact guarantee.
• NR can be enabled or disabled from the Flutter API, with a strength control. Exact range is agreed in Alpha.
• Advanced AI / aggressive suppression is out of January and may be evaluated later.

3.5 January pitch correction, feedback, and singing score

StarManch: Include initial pitch correction, feedback, and score in January.
daudio::dev: Accepted.

• Real-time pitch detection with sharp, flat, and in-tune status exposed to Flutter.
• Initial Auto-Tune-style correction with agreed controls and documented limitations.
• Melody-based singing score using supplied reference melody and timings.
• Pitch analysis and scoring on the dry vocal path, independent of wet FX.
• Flutter APIs sufficient to render pitch feedback and score UI.
• Alpha measurable pack, on a small set of test songs agreed at kickoff or early Alpha (melody JSON + backing tracks from StarManch): live sharp / flat / in-tune status, correction on/off, and a melody-based singing score vs that JSON, all callable from Flutter.
• Before Alpha validation we agree in writing: the score values Flutter receives (for example 0–100 or another scale), what they mean, how pitch and timing map into the score, and the correction controls and ranges. Schema and sample melody JSON are in Appendix C. The score is an engineering estimate of pitch accuracy against the reference, not a judgment of overall singing quality.
• January: the same measurable pack as working v1 in the full app workflow, production-ready on the locked device set.
• Lower-end device limits are documented with an agreed fallback (for example lighter live correction, stronger post/export, or later polish). Advanced correction and richer scoring can follow after the initial release.

3.6 POC, Alpha, and January test devices

StarManch: Finalise 2–3 devices jointly for POC. Tiers mid / high / lower-mid if available.
daudio::dev: Accepted.

• Exact manufacturer, model, chipset, Android version, and build recorded in the POC report.
• All below-30-ms measurements use wired earphones and the jointly agreed methodology.
• Both teams exchange device inventories and lock the matrix before the POC measurement session.
• Same lock rule for Alpha and January: models and OS builds are locked jointly before each milestone starts. Acceptance for that milestone is judged on the locked set; other devices are out of scope unless both sides add them in writing.

Our available Android test-phone inventory is proposed in Appendix D.

3.7 Additional controls

StarManch: Proposed initial set approved.
daudio::dev: Accepted.

Baseline:

• Preset
• Vocal / music volume
• Overall preset-effects intensity
• Reverb
• Delay
• EQ Low / Mid / High
• Vocal latency offset −250…+250 ms

• API remains modular / extensible.
• If a new control would affect the DSP architecture, monitoring latency, or delivery dates, both sides review it as a written change request.

3.8 Lyrics sync, seek, and same-session re-record (clarified product behaviour)

StarManch: Flexible karaoke recording without restarting the whole song — keep vocal before the selected line, re-record from that line to the end, and seek forward/back without listening through the track.
daudio::dev: Accepted as option A for January. This supersedes mid-section punch-in that keeps audio after the edit point.

The SDK will support, in a single recording session:

• Lyrics synchronisation: stable playback-position API/callback (ms) for Flutter.
• Lyrics-based seeking: select any lyric line or timestamp. The backing track seeks automatically.
• Same-session re-record: everything recorded before the selected line is kept. From that line to the end, the previous vocal is replaced. Recording continues without starting a new session.
• Skip ahead: Skipped regions are silent on the vocal track. Export length still matches the backing track. The session continues from the new position.
• Timing accuracy across seek, pause/resume, and re-record.
• Session continuity: seek must not terminate the session or discard vocal recorded before the seek point.
• January option A edges: seek mid-phrase is OK. Under agreed test seeks on the locked devices, the splice should not introduce an audible click or discontinuity. Playback position stays continuous, and export length equals song (backing-track) length.
• If the user seeks back, starts re-recording, then stops before the song end, vocal from the seek point to the end is treated as replaced for that take: new audio is kept up to the stop point, and from the stop point to the end is silent, so export length still matches the backing track.

Example: 20 lyric lines. Mistake on line 10 → select line 10 → music seeks → lines 1–9 kept → re-record from line 10 to the end → prior vocal from line 10 onward replaced.

Out of January scope: mid-section punch-in that replaces only a middle region and keeps audio already recorded after that region. That may be scoped later if required.

Flutter handles the lyric UI. The SDK handles playback, seek, and same-session re-record.

3.9 Interruptions and cue points

StarManch: App owns OS audio-focus and lifecycle. SDK provides safe pause/resume/reset/reinit.
daudio::dev: Confirmed.

• With SDK-owned backing, mic, monitoring, recording, and music pause/resume together.
• Default after interruption: last lyric line. Exact timestamp remains available via API.
• Same continue-from-there recording behaviour as §3.8 (option A).
• Cue / song-position exposed so the app can restore the correct place in the track.

For the default (last lyric line), StarManch supplies timed lyric markers (line index and start time in ms). That is the same timing data used for lyric sync and seek in §3.8. The SDK reports playback position. The app maps that position to the last started line. Exact timestamp resume needs no extra file, only the live playback position.

4. Architecture and platform

4.1 Architecture

• Shared C++ engine: DSP, effects, recording, sync, post-processing, mixing, export via a stable C API.
• Android: Oboe / AAudio. .so + Kotlin/Java (JNI) or AAR.
• iOS: Core Audio / AVAudioEngine. XCFramework.
• Flutter: documented Dart API + MethodChannel. Minimal Flutter test app (start/stop and basic engine controls — not the StarManch karaoke UI).
• The SDK is independent of ZEGOCLOUD for standalone recording, post-processing, and export. ZEGOCLOUD live remains separate. Future live DSP injection is separate scope.

4.2 Platform and audio specifications

• Internal DSP: 32-bit float PCM.
• Mic: mono 44.1 or 48 kHz (48 preferred where supported).
• Backing: stereo MP3 / WAV / M4A (AAC).
• Export: stereo M4A + MP3 as in §3.2.
• Android: API 24+ onward. Mandatory arm64-v8a. armeabi-v7a if practical.
• iOS: 15.0+. XCFramework ios-arm64 + agreed simulator architectures. Consistent API where practical.

4.3 Monitoring and latency

• Independent low-latency capture and headphone monitoring.
• Below 30 ms round-trip is our performance target on the jointly agreed wired-earphone test devices. It is not a blanket guarantee across every phone.
• StarManch listed below 30 ms as a POC acceptance criterion. We propose this acceptance rule: POC pass for latency means results are measured and documented on the locked wired Android POC devices with the agreed method. If a locked device comes in above 30 ms, both sides agree in writing whether that result is accepted for POC or needs more work. Android POC latency does not prove iOS latency. iOS is measured later on the locked iOS set.
• The agreed POC latency measure is Oboe’s reported input, output, and round-trip (sum), exposed in the Flutter test app. An acoustic clap or loopback check on the locked wired devices may be run as an extra reference. It is not required for POC pass unless both sides add it to the written POC checklist before testing.
• The below-30 ms target applies to the locked wired POC devices that provide a usable low-latency Android path (AAudio / MMAP where available). It is not a promise for every API 24+ device.
• Bluetooth and loudspeaker excluded from that target (BT warn / allow disable, and mute speaker monitoring to prevent feedback).
• Headset routing detection where supported. Flutter fallback if OS reporting is unclear.
• Vocal latency offset −250…+250 ms. Same offset in final export.
• On Android, POC latency uses the Oboe measure in §4.3 above. We will measure with effects both on and off. Dry recording is not delayed by wet monitor FX.
• Device-specific limitations, glitches, dropouts, and fallbacks documented in POC/Alpha reports.

4.4 Dry / wet workflow and duration

• Live wet monitoring. Mandatory dry vocal recording. Post-recording FX adjustment without re-singing. Final mix of dry + FX + backing to M4A/MP3. Separate wet file optional.
• The singer can hear effects in the headphones while we still save a clean dry vocal. Pitch and score also use that clean vocal, not the wet headphone mix.
• Full-song sessions, practical target ~8 minutes. App provides sandbox paths (path_provider). SDK writes only to those paths.
• Session controls: start, stop, pause, resume, reset, and reinit, with state and error events to Flutter.

5. Effects, pitch, score, and NR

Covered under §3.4, §3.5, and §3.7. January effects include:

• Room / Hall / Plate reverb
• Delay / echo
• Multi-band or 3-band EQ
• Compression
• Peak limiting
• Vocal / music balance
• January vocal presets: Studio, Pop, KTV/Karaoke, Concert, Ballad, Warm R&B
• Realtime monitoring
• Consistent post-recording adjustment / offline export

6. Milestone alignment and acceptance

We’re suggesting kickoff for 3 November 2026, which keeps us on track for the POC on 23 November 2026.

6.1 POC acceptance conditions

1. Independent native microphone capture on all agreed POC devices.
2. Audio passes through the native C++ engine with passthrough/gain.
3. Round-trip monitoring measured and documented on the locked wired Android POC devices against the below-30-ms target, using the proposed acceptance rule in §4.3. If a locked device is above 30 ms, both sides agree in writing whether that result is accepted or needs more work.
4. No obvious clicks, dropouts, or glitches under agreed test conditions.
5. Flutter test app demonstrates start/stop and basic audio-engine controls.
6. Written confirmation that the architecture can support later dry recording, effects, pitch/score, synchronisation, seek/re-record, post-recording adjustment, and export (plan in report — not built in POC).
7. Interruption handling, audio-session behaviour, backing-track synchronisation, and option-A seek/re-record approach documented.
8. Technical plan for extending the validated Android approach to iOS delivered.

Out of POC: full FX, pitch/score, full dry/post/export, production iOS, production seek/re-record.

6.2 Alpha and January acceptance (summary)

Alpha acceptance

• Dry vocal is saved during the session, and the singer hears realtime wet monitoring with the core FX chain running
• Native SDK plays the backing track in sync with the mic session (app provides the file path)
• After recording, the user can change FX and preview without singing again
• Export produces a usable stereo M4A or MP3 mix to an app path (defaults and polish can still improve in January)
• Pitch measurable pack on the agreed Alpha test songs: live sharp / flat / in-tune, correction on/off, and melody-based singing score vs melody JSON via Flutter (score scale agreed before Alpha validation; not final sound quality)
• After pause for an interruption, default resume is the last lyric line. Exact timestamp via API also works well enough for Alpha testing
• Seek to a lyric or time and continue recording from that point (option A) works for Alpha testing. Edges can still be rough
• iOS build can create, start, stop, and record on the same basic API shape as Android (not final iOS polish)
• On the locked POC Android devices, Alpha monitoring still works at least as well as the accepted POC (no new serious clicks, dropouts, or breakage of the mic-to-headphone path).
• Alpha acceptance is judged on the device models locked before Alpha starts; other devices are out of scope unless both sides add them in writing

Items labelled Alpha do not fail only because they are not yet production-polished for January.

January acceptance

• Full recording workflow works on the locked January Android and iOS devices (mic, monitor, backing, record, seek, export)
• Core FX and the six presets (Studio, Pop, KTV/Karaoke, Concert, Ballad, Warm R&B) work in realtime and after recording
• Dry vocal is saved, post-recording FX preview works, and final stereo export is available as M4A and MP3 with progress / done / error callbacks
• Vocal latency offset (−250…+250 ms) can be set in the UI and is applied correctly in the final mix
• Full-song sessions of about 8 minutes work under the agreed test conditions
• Working v1 pitch correction, sharp / flat / in-tune feedback, and melody-based singing score vs StarManch’s melody JSON (usable in the app on the locked January devices. Score scale as agreed before Alpha)
• After an OS interruption, default resume is the last lyric line (exact timestamp via API), then continue recording from that point
• Option A seek / re-record is production-usable: keep vocal before the selected line, re-record from that line to the end in the same session. Seek mid-phrase OK. Under agreed test seeks on the locked devices, the splice should not introduce an audible click or discontinuity. Position continuous. Export length equals song length
• Skipped regions are silent on the vocal track. Export length still matches the backing track
• Simple noise gate / light NR is available, switchable, with documented limits on agreed devices
• Packages, API docs, and known limitations are delivered
• Hybrid licence: SDK source delivered after January acceptance and full payment
• No open critical defects that block core recording, block M4A/MP3 export, or cause crash on launch on the locked January devices

Missing below-30 ms on non-agreed devices, Bluetooth, or loudspeaker is not a fail.

6.3 Early exit and phase exit

After a milestone is accepted (or that phase is closed), StarManch may stop and not continue to later milestones. In that case we deliver the compiled builds, documentation, test reports and the Flutter test app for the paid work on that phase. The contract ends for later milestones with no obligation on either side to continue.

If a phase does not pass its acceptance list, StarManch sends a short written note tied to those points. We then have 10 business days to fix the issues and resubmit (or another window we agree in writing). If we still cannot agree, or either side would rather stop, we close that phase in good faith. You keep what was already paid and delivered, including compiled builds, documentation, test reports and the Flutter test app for the paid portion of the phase in progress. There is no obligation to move on to later milestones.

Paying for a milestone alone does not transfer ownership of the reusable audio engine. daudio::dev retains all rights to the reusable audio engine. No engine source code is delivered on early exit. The full reusable SDK source package is delivered under the hybrid licence in the Services Agreement only after January acceptance and full payment.

6.4 Schedule assumptions

POC 23 November 2026, Alpha 31 December 2026, and January release 31 January 2027 assume timely devices, test assets, melody JSON, feedback, and decisions from both sides. We will list the main dependencies and needed dates at kickoff. If something on that path slips, the affected milestone date may need to move. Any change to dates or cost will be agreed in writing before we proceed.

7. Responsibilities and dependencies

8. Commercial proposal

Why the totals differ from the earlier quote

The earlier package was €8,700 without NR (€9,300 with NR). This final proposal is €8,900 / €9,500. The +€200 is for cue and song-position support we discussed over the phone, included in Milestone 2 (Alpha). The Milestone 2 fee of €3,700 includes that €200.

Post-January consultancy

After January acceptance, paid consultancy is available if you want ongoing help beyond the 90-day warranty. That can cover the music and karaoke experience in your app, for example how singing, monitoring, effects, lyrics, and re-take flows feel for the user, and how to shape those moments so the product feels like good music software. We book this as a consultancy meeting at €150 per meeting (1–1.5 hrs). Bug fixes for material defects on agreed devices stay under the 90-day warranty (90 days from January acceptance. Excludes new features and non-agreed devices) and are not charged as consultancy.

Payment schedule

• M1: 50% on kickoff · 50% on POC acceptance
• M2: 50% on Alpha start · 50% on Alpha acceptance
• M3: 40% on release start · 60% on January acceptance
• Simple NR: 50% when NR work starts · 50% on NR acceptance with the January milestone (same invoice cycle as M3 acceptance unless we agree otherwise in writing).

9. Open items and next steps

Please confirm acceptance of this proposal in writing (email is enough). That locks the decisions already Accepted in this document, including option A and the commercial totals. Kickoff work and the first invoice follow that written acceptance.

Still open before kickoff

• Lock 2–3 POC Android devices, OS builds, and wired earphones (our list: Appendix D)
• Confirm the proposed POC latency rule in §4.3 and the written POC checklist
• Define the option A test seeks and splice crossfade length in the POC checklist
• Confirm kickoff owners for 3 November 2026
• Review Appendices A–C (Flutter API, position/seek, melody JSON)

Still open at kickoff / in Alpha

• Default bitrate, score scale/rules, and control ranges: agree at kickoff / in Alpha as noted in the body
• Written score-scale agreement before Alpha validation (see §3.5)

Then we proceed to the Services Agreement / DocuSign. Once signed, the Services Agreement prevails over this proposal in case of conflict.

POC 23 Nov 2026 · Alpha 31 Dec 2026 · January 31 Jan 2027

10. Closing

We hope this proposal lines up with what we discussed. Please confirm acceptance in writing (email is enough). After that, plus the open items in §9, we are ready for kickoff and the Services Agreement / DocuSign.

Regards,
daudio::dev Product & Engineering
dessy@daudio.dev · daudio.dev