What should happen when you delete a voice recording?

Development source review · 2 October 2026: The Ptichi behavior described here comes from desktop source code and regression-test definitions. We did not run a native app, storage test or microphone test for this article. There is no public desktop release or installer. The current website does not record audio.

The difficult part is that “my recording” can mean several things. There is the audio you can play. There is the practice history that says which attempt it was and what you changed. There may be an exported file in another folder. An app can remove one of these while another remains.

A useful deletion control needs a precise object. So does a useful decision to keep something.

Start with the question you may want to answer later

Consider this authored example, written to explain the choice rather than report a user result.

You rehearse an explanation of a delayed delivery. Take A includes a long account of what went wrong. In Take B, you put the new delivery date first. You then try the same approach with different wording. After the real conversation, you want to clear the rehearsal.

If your only future need is to hear the final wording again, one selected recording may be enough. If you want to compare how the opening changed, keeping only Take B removes half of that comparison. If the recordings contain details you no longer want to retain, a useful exercise does not create an obligation to preserve them.

These are different retention decisions:

• Keep a reference: retain the particular take you want to hear again
• Keep a comparison: retain the attempts and enough context to understand the difference
• Finish the rehearsal: delete the material when it has served its purpose

Our recommendation is to name the future question before keeping the files. “I want to hear whether the date came before the explanation” is a reason. “Something useful might be in here one day” is much harder to review.

Keeping a comparison also has limits. Two recordings let you revisit what happened in those attempts. They do not, by themselves, establish that another listener understood more or that the change will last. A retained practice history should help you inspect evidence without making that evidence stronger than it is.

Why Ptichi retains source audio, and why that does not settle your choice

Our accepted architecture decisions keep raw audio and personal history local by default, prohibit silent uploads, and preserve source recordings alongside information about how their analysis was produced. The reason for retention is concrete: an analysis method can change, while the original recording remains available to hear or examine again.

That creates value and responsibility at the same time. More retained audio means more local storage and more material to manage. The possibility of a better future analysis is not a sufficient reason to keep every rehearsal indefinitely.

The current retention policy has no automatic age-based pruning. It discusses possible later controls, such as keeping selected important takes while removing older practice audio. Those are design candidates, not controls a reader can use now. We have no source-backed basis for recommending a universal number of days to retain a voice recording.

Another candidate is to keep historical measurements after removing their source audio. That would require a clear warning that replay and any new analysis needing the audio are unavailable. It must not quietly make a surviving number look fully inspectable. The current deletion controls described below should not be read as an implemented “keep my scores, delete only the sound” mode.

For now, the practical distinction is between retaining a saved practice, exporting selected sound, and deleting the practice. Choosing among them starts with what you want to preserve, not with how many files an app can store.

Export preserves the sound, not the whole practice

In the current desktop source, the recording export flow asks you to select one saved take and choose a destination through the system save dialog. It checks the stored audio's identity and writes the original WAV bytes. A missing or altered source cannot become a successful export.

The output contains no added exercise text, comparison judgment or archive of analysis results. Export also leaves the managed recording unchanged. You now have another copy; you have not moved the practice out of Ptichi.

Return to the delivery example. Exporting Take B preserves the sound of that take. It does not package the fact that the new date was your listening focus, preserve Take A, or create a restorable copy of the session. If you export two takes for a later comparison, you must keep track of which is which. A short note without confidential details may be useful, but it is another item to manage.

We deliberately describe this as a selected audio export rather than a full backup. Treating a WAV as a session backup would invite a painful discovery after deletion: the sound remains, but the practice context you expected to recover does not come with it.

The source also rejects export destinations inside the managed profile and refuses to overwrite an existing target. Cancelling the save dialog creates no export. These checks protect the managed source and unrelated files; they cannot choose an appropriate external destination for you.

The WAV is saved without encryption. A random suggested filename does not hide what someone can hear inside it. If the chosen folder is synced or backed up, other software may copy it. Export is therefore useful when you want to retain sound independently, but it is a poor automatic first step when your actual goal is to stop retaining that sound.

A practice, a lesson reset and an activity history have different scopes

The current Recordings view confirms deletion of a practice and its managed recordings. That is important when the practice contains Take A, Take B and a changed-wording attempt. Selecting one take for export does not narrow the separate session-deletion action to that take.

The broader recording-data control removes saved sessions, their managed recording sources and lesson progress. It preserves language preferences. It is not a complete reset of every piece of local application state.

Lesson reset has its own ownership problem. The source gathers recordings from both the lesson's visible attempt summaries and its durable record of ownership. It then removes the lesson's progress and queues sources that no other practice or lesson still owns. Tests include older data in which two lessons refer to the same recording: resetting one must leave the other lesson's source available.

That check matters because “start this lesson again” must not silently destroy sound still belonging to something else. It does not mean that the app is hiding a deleted copy. It means the same source still has another retained owner. Nor does the test imply a released feature for sharing recordings between lessons.

There is a further distinction between saved practice history and product-event history. The local event record describes bounded steps through the app, such as reaching a practice milestone. It excludes the recording and practice text. It can still contain timing, categories and local identifiers, so “there is no audio in it” is not the same as “there is no history.”

Deleting recordings does not clear those earlier events. They have a separate deletion control. Pausing future event recording and deleting past events are also separate actions: clearing the past does not turn future recording off, and turning it off does not clear the past. The Microphone Passport, which records setup information, has its own deletion control too.

Our design interpretation is that separate controls can avoid unwanted side effects. Someone removing a rehearsal should not have to choose their interface language again. The cost is explanation: an empty recordings list must never be presented as proof that every kind of local history has gone. The privacy page remains the canonical explanation of those data boundaries.

When the item disappears before cleanup finishes

Removing a recording involves two kinds of storage: database entries that describe the practice, and files that hold the audio. A failure can occur between changing one and changing the other.

Imagine that the app removes a session from its database, then closes before removing the WAV files. If it forgot which files still needed deletion, the next launch could show an empty history while leaving the sound on disk.

The current storage code addresses this with a pending-deletion record. It commits the list of sources to remove together with the database changes, then removes the files. It clears each pending entry only after that file removal succeeds or the file is already absent. If cleanup fails, the operation returns a cleanup-pending error rather than an unqualified success.

Startup attempts to finish pending deletions. A regression test constructs exactly this intermediate state: the database removal has been committed, the selected file still exists, and a different recording must be preserved. Its assertions require the selected file to disappear after reopening, the other recording's bytes to remain unchanged, and the same result to hold after a second restart.

That is a test definition we inspected, not a test result produced for this article. It makes the intended failure behavior concrete. It does not establish how every packaged build behaves under disk failure or sudden power loss.

Recovery also needs to respect a deletion decision. Before delete-all, the code resolves unfinished saved-take work so those sources enter the same ownership and deletion process. Otherwise, later recovery could bring back a take the person thought the broad deletion had covered.

This recovery machinery is not an Undo feature. Its job is to finish the recorded operation consistently. After a deletion has been committed, finishing it means removing the remaining managed file, not restoring the practice because its bytes happen to be present.

The lesson for the reader is modest but useful: a disappearing row is weaker evidence than a completed operation. If an app reports incomplete cleanup, treat that report as unresolved. Use its supported retry or recovery path; do not assume that hiding the item or repeatedly pressing different reset buttons has solved the storage problem.

Local control has an outside edge

The managed profile gives Ptichi a defined place in which to identify and remove its own recording files. Cleanup recognizes reviewed file shapes and preserves unrelated filenames and directories. The app should not search the rest of your computer for similar audio and delete whatever it finds.

That limit is protective. An exported WAV may be the reference you deliberately chose to keep. Another copy may belong to a different project. Similar sound is not authority to remove a file.

It also means that a complete in-app deletion cannot answer every question about copies. An export in another folder, a file already shared through another app, or a backup may remain. Those locations have their own controls. Ptichi cannot claim to recall them through its recording-delete button.

Nor does ordinary file removal establish secure erasure from the physical storage device. This source review supplies no guarantee about residual bytes, operating-system backups, synced copies or another person's access. We make no secure-erasure claim.

The strongest product uncertainty is whether people can understand these scopes before committing to deletion. Code and synthetic tests can check that a selected file is removed while another is preserved. They cannot show that a reader correctly predicts what “delete practice” or “reset lesson” will do.

We would revisit the labels and grouping if observed use showed people exporting material they meant to remove, losing a comparison they meant to keep, or reading a cleared list as a complete privacy reset. Those are questions for actual use, not outcomes we have already observed.

Try a small retention decision before the next real rehearsal

You can check your own workflow now with a recorder you already use. Choose a disposable, non-confidential recording, not a file you would regret losing.

1. State the purpose. Write one sentence explaining what you would want to hear again. If there is no future question, decide whether you need to keep the recording at all.
2. Find the deletion scope. Read what your recorder says it removes: one take, a whole session, local files or a synced collection. If this is unclear, stop before deleting anything important.
3. Inspect one export only if you want a separate copy. Open it from the chosen destination and listen. Check whether it contains just audio or any practice context you expected. Remember where you saved it.
4. Delete only the disposable test item. Check the app's completion or error message. If you made an export, check that separate location too. Its continued existence tells you about that copy; it does not prove that no other copies exist.

This is a handling check, not a security audit. It gives you a clearer decision before a rehearsal includes material you care about.

For the speaking practice itself, Boundary contrast offers a short, authored two-take exercise with a changed-wording step. You can use its non-confidential material to decide whether keeping one reference, the comparison, or neither serves your next practice.

The useful result is a choice you can explain: what you are keeping, why it remains useful, and which deletion control covers the rest. A trustworthy app should make that choice easier to carry out and make any unfinished part visible.