Technical Case Study of Cloud Audio Editing: Challenges, Solutions, and Optimization

In this article the author shares the experience of taking over the development of the Cloud Editing project, an audio editing tool for the Ximalaya Creator Center. The narrative starts with personal feelings about the project and quickly moves to a systematic approach for handling a new, complex codebase.

New Project Entry Points

Fully understand the business to avoid creating new pitfalls.

Meticulously map the entire workflow from input to output.

Set clear goals, face challenges, and design appropriate solutions.

The author emphasizes that technology should serve the business, advocating simple and feasible solutions over flashy new features.

Key Difficulties Encountered

Slow waveform loading.

Severe zoom lag.

Long operation waiting times.

Frequent user complaints about “stuttering”.

High‑profile streamers publicly criticizing the performance.

Additional storage‑related challenges include poorly designed IndexedDB usage, lack of upgrade mechanisms, no transaction support, inability to clean up data, and low file size limits.

Competitor Analysis

Product A (a fast, built‑in‑material web editor) offers concise waveform rendering, rapid handling of short audio clips, smooth zoom, minimal requests, and limited features.

Product B (a mainstream desktop editor, e.g., Adobe) provides smooth zoom, balanced performance, rich professional features, but requires higher hardware specifications and does not support cross‑device sync.

Goals – Eliminate Stutter

Fast waveform presentation to reduce loading time.

Lag‑free zoom for smooth interaction.

Overall seamless experience from upload, rendering, editing, to final export.

Proposed Solutions

1. Process Refactoring : Introduce multi‑file queue management with front‑end transcoding, split and decouple rendering components, and apply scientific memory, cache, and IndexedDB usage.

2. Storage Governance :

Standardize IndexedDB operations and entry points.

Support multi‑table, multi‑transaction operations.

Enable large‑file chunked storage.

Provide user‑side IndexedDB upgrades.

Redesign tables and indexes.

3. Monitoring & Cleanup (implemented by @卢丹丹):

When cleaning audio, also clean sample and waveform data.

Periodically monitor remaining storage space.

When reaching a threshold, batch‑clean early data.

Release Tracking & Feedback

Separate internal testing deployment for early user feedback.

Document issues found in the test version and prepare mitigation points for the official launch.

After release, maintain a feedback tracking sheet to categorize recurring problems.

Assist users with troubleshooting and recommend browser upgrades.

Drive algorithmic optimizations for rare edge cases.

Optimization Results

A 70‑minute, 68 MB audio file processing time reduced from 226 s to 102 s; a 5‑minute, 13.3 MB file reduced from 49 s to 10 s.

Zoom operation time dropped from 63 s (old version) to 22 s (new version).

Page refresh time decreased from 50 s to 5 s.

Self‑Reflection

Adopt aspect‑oriented programming and localized refactoring for complex problems.

Handle major iterations with caution and thorough pre‑release preparations.

Control release cadence to ensure reliability.

Provide user prompts and announcements when IndexedDB upgrades are required.

Implement proper instrumentation at critical workflow points to enable data‑driven issue discovery and resolution.