SleepTrace：收集了 1,045 小時睡眠音訊，只有 53 小時可用於訓練

We have 1,045 hours of overnight bedroom audio. For training a sleep-phase model, about 53 of those hours are usable.

That ratio is the least glamorous number in this project and probably the most important one. People argue about model architecture. Almost nobody talks about the fact that, for a long time, every additional hour of audio adds almost nothing you can actually learn from.

Recording a night is easy. Having something to learn from is expensive

Capturing audio overnight is a solved problem: a ring buffer, a phone on the charger, a file in the morning. We had thousands of hours before the model was worth training.

The hard part is the label. To say "this 30-second window is deep sleep" you need a reference you trust. Ours comes from wearable staging, but only on nights where the phone recording and the wearable recording overlapped cleanly.

That word, cleanly, is doing a lot of work.

Two devices mean two clocks, two ideas of when the night started, and two chances to fail independently. A drift of a few seconds is irrelevant to a human reading a hypnogram and fatal to a model that classifies in 30-second windows. A night where the wearable died at 4am is not a shorter night, it is a night with no label for the second half.

Each of these problems quietly deletes hours.

30 valid nights out of 111

In one of our recording tables there were 111 rows. Thirty of them were real nights: actual sleep onset, full duration, phone left alone. The rest were aborted starts, test recordings, phones picked up again at 3am, or recordings that never reached a sleep onset at all.

That is not a data problem in the machine-learning sense. It is a definition problem. You cannot start learning until you have written down what a valid night is, and once you do, you have to throw away most of what you collected.

The uncomfortable part: throwing data away felt like losing progress. It was the opposite. Before we were strict, a chunk of the training signal was noise wearing a label.

Three changes that did most of the work

Recording table discipline. Every recording has a reason to exist, a note on whether sleep onset is present, and a flag for completeness. If a night is incomplete, it is not silently averaged into the set.

Alignment before labelling, never after. We stopped matching audio to wearable output by human guessing of start times. Alignment is a step with its own failure modes, and it runs first. If alignment is not confident, the night does not get a label.

Label provenance. Every label remembers where it came from. When the reference is a wrist device, that is part of the label's meaning, not an implementation detail to hide. Audio can hear snoring and breathing events that a wrist cannot feel, and a wrist can measure things audio cannot hear. Being explicit about which source stands behind which number keeps us honest.

None of this is clever. It is bookkeeping. Bookkeeping is what makes the rest possible.

The Android port as a sanity check

We ported the analysis from Core ML on iPhone to ONNX on Android. Given identical input, the two engines agreed to within 2.9×10⁻⁶.

That number is not a benchmark and it is not marketing. Its only job was to answer one question: if the two platforms disagree in the morning report, is it the model or the plumbing? Now we know the plumbing is not the answer. That kind of boring equivalence check saves weeks of chasing ghosts.

Why the ratio matters beyond our app

Sleep apps publish accuracy figures without saying what the reference was. A number like "92% accurate" is meaningless until you know how many hours had a trustworthy label, how the nights were aligned, and what got thrown out.

With a 20:1 gap between data and data you can learn from, the denominator matters more than the model. Anyone who says otherwise either has a lab, or has not looked at their own dataset closely enough.

We publish our numbers, including the unflattering ones, at sleeptrace.app/methodology. The app records the night, classifies sleep phases and events on the device, and keeps the audio as evidence you can actually play back. It is a wellness app, not a medical device, and phase estimates from sound alone are estimates.

If you are building anything that learns from messy real-world recordings, the useful question is rarely "how much data do we have". It is "how much of it would survive a strict definition of usable", and then what you are willing to delete.