Recording Metadata: Export and Mapping

What stalls a migration is rarely the audio

When a recording migration stalls halfway, the audio is rarely the reason. The proprietary container gets parsed, the codec gets identified, the WAV files come out in bulk, and a few hundred thousand files sit neatly in the new archive. Then compliance asks for one specific call, on a given date, handled by a given agent, with a given phone number, and nobody can produce it. The fields that decide whether a single call can be located almost never live inside the audio file. They live in the database of the original platform: call start time, agent ID, calling number, called number, call direction (inbound or outbound), duration, and the business reference number that ties the call back to the transaction system. Without them the export is playable but not searchable, and playable on its own is worth close to nothing. Nobody listens through three hundred thousand files one at a time.

Two ways the mapping breaks: it snaps, or it lies

The link between audio and metadata is normally established by a column in the source database that points at storage: each call record carries a path, a file name or an internal ID for its recording. The weakness is that this link is an external convention rather than a property of the file itself. Rename the files during export, reorganize them into date-based folders, or merge several batches into one flat directory and collide on names, and the link is gone. Rebuilding it afterwards means guessing from the few physical traits the audio still has: duration, file size, modification time. Across hundreds of thousands of records there are many calls that start in the same second and run for the same number of seconds, and nobody will stake a regulatory request on that kind of guess. The mapping has to be fixed in place in the first step of the export, not reassembled at the end. The second failure mode is quieter: the mapping holds, but the time itself is wrong. What the platform database stores has to be confirmed per deployment. Some keep server local time with no zone marker at all, some keep UTC, and some mix the two across different tables. Without an offset the column is ambiguous: cross-timezone retrieval lands hours away from the real call, and on daylight saving transition days one hour is duplicated or missing outright. The safe practice is to export three things together: the converted UTC timestamp, the original value exactly as stored, and the zone and offset that original value belongs to. With all three present, any later disagreement can still be traced back. With only a converted result, an error becomes permanently invisible.

What a searchable export looks like

1. Treat the metadata as the primary index rather than an attachment: one row per call record from the source database, each row carrying a relative path to a specific audio file, with that column unique across the whole export.
2. Split time into three columns: a UTC timestamp, the original stored value verbatim, and the zone or offset it belongs to. A single column called time is not enough.
3. Write the field and value mapping down as a document. Call direction may be 1 and 2 in one system and I and O in another, and agent IDs may exist in two tables under two numbering schemes. That mapping belongs in a document, not only inside a script.
4. Pick a structured format that can be loaded directly, such as CSV, JSONL or Parquet, rather than a hand-maintained spreadsheet. Hundreds of thousands of rows exceed spreadsheet row limits and offer no way to enforce a primary key.
5. Run a two-way check immediately after export: every metadata row resolves to a file, and every file resolves back to a row. Both difference sets must be empty, and both results must be recorded.
6. Put the source record count, the exported count, the missing count and the time distribution of the gaps into a verification report. That report is the actual proof that the result is searchable.

How Shanghai Wanchun approaches it

We work on parsing and migrating historical call center recordings, and metadata is never treated as an add-on to the audio. It is a deliverable of equal weight: the full set of search-critical fields is extracted from the source platform database, mapped record by record onto the decoded audio and fixed in place, time fields are exported under the three-column convention described above, and the result is a structured index that can be loaded straight into a retrieval system, accompanied by a verification report reconciled record by record against the source database. The goal is always the same: historical recordings freed from any single vendor, permanently online, retrievable on demand, searchable and ready for analysis.