Rebuilds a Melognite piece from the recipe recorded in its certificate and compares the fingerprint of every track. The check runs in this browser window. No data is transmitted or stored.
Melognite is a rule-based, deterministic composition engine. A piece is fully determined by its recipe (the seed and every setting) and by the engine generation that processed it. For every export and every studio recording the engine writes a provenance certificate, a plain text file that records the recipe, the engine generation, the script versions, the named sound sources with their licences, and a SHA-256 fingerprint of each track, computed over the canonical list of notes (pitch, start, duration, velocity).
Since certificate format 2 the certificate also records the SHA-256 digest of the delivered file, the .mid, the stem files or the .wav. The ZIP archive is the unit: the file and its certificate belong together, and the digest ties them.
This service performs two checks. First, the file binding: the digest of the attached file is computed here and compared with the digest recorded in the certificate. Second, the reproduction: the same engine rebuilds the piece from the recorded recipe, computes the fingerprints again and reports, track by track, whether they agree. Together they establish that the attached file is the file Melognite delivered, and that its drums, bass, chords, melody and other parts follow from that recipe on that engine. What a user did with the file afterwards, in a DAW or a mix, lies outside this check.
.mid file, or next to the stem files, it contains …_CERTIFICATE.txt..wav file, the licence note and …_CERTIFICATE.txt.?r=…) carries the same recipe. It can be submitted here as well; the result is a set of reference fingerprints without a certificate to compare against.Keep the certificate with the audio file. If the origin of a release is questioned, submit the certificate here, or several certificates when parts of a release stem from different pieces, and refer to the resulting report.
No report yet. Submit a certificate above.
Reproduction. The genre page named in the certificate is loaded invisibly within this origin and receives the recipe exactly as a shared link would. The page builds the piece through the same path a user's click takes, including all post-processing stages. After the build completes, the note lists of all tracks are read from the page.
Fingerprint. For each track the notes are sorted by start, pitch and duration and serialised as [pitch, start, duration, velocity] with start and duration rounded to four decimals. The track fingerprint is the SHA-256 digest of that serialisation; the total fingerprint is the digest of all track fingerprints together with tempo, metre and section list. A single altered note changes the fingerprint of its track.
Verdict. A certificate is reported as reproduced only when the total fingerprint and every track fingerprint agree. If some tracks agree and others do not, the report states which.
Engine generation. Fingerprints are only comparable across the same engine generation. The report shows the generation recorded in the certificate and the generation that performed the check. When they differ, a mismatch may be caused by the engine update rather than by the file; the certificate remains a valid record of the generation it names.
File binding. The certificate of format 2 lists each delivered file with its size and SHA-256 digest, computed over the bytes exactly as written into the ZIP. This page computes the digest of an attached file with the browser's own SHA-256 implementation and compares it with the certificate. A file that has been re-saved, re-encoded, trimmed or otherwise altered no longer matches; the binding then states that the attached file is not the delivered one. Certificates of format 1 carry no file digest and are reported without a binding.
Not covered. Audio is not analysed; the WAV is bound as a whole file. What happens to a file after delivery, editing, mixing or re-export, is not attested by the certificate and must be documented by the user. Certificates are written by the browser at export time and are not yet signed by the service; a signed variant with a service-side record is in preparation.