An audio file exporting method and device, electronic equipment and storage medium
By generating a persistent export list and file handle in the IndexedDB database, and restoring the ability to stream and retrieve audio files in the background, the export problems caused by excessive browser memory spikes and network anomalies were resolved, achieving efficient and stable export of audio files.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- XIAMEN XINGZONG DIGITAL TECH CO LTD
- Filing Date
- 2026-04-29
- Publication Date
- 2026-07-21
AI Technical Summary
In call center quality inspection platforms and monitoring recording archiving platforms, existing technologies are prone to causing excessive browser memory spikes when exporting large-capacity recording files, leading to tab freezing or crashes. Network anomalies can also cause task failures, disrupt user authorization processes, increase operational burden, and easily result in duplicate files and inconsistent archiving locations.
By generating a persistent export manifest and file handles and storing them in the IndexedDB database, permission checks and streaming of audio segments are performed. The browser's background retrieval capabilities are used for task recovery, avoiding duplicate authorizations and repeated file path selections, and ensuring stable file storage to disk.
It improves the export efficiency of large-capacity recording files, reduces the burden on users, reduces duplicate files and overwrite errors, and improves the overall throughput efficiency in weak network and multi-connection scenarios.
Smart Images
Figure CN122432376A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of audio processing, and in particular to a method, apparatus, electronic device, and storage medium for exporting audio recording files. Background Technology
[0002] In web applications such as call center quality inspection platforms and monitoring recording archiving platforms, users need to export large numbers of recording files in batches, with single export volumes reaching GB or even over 10GB. However, related technologies typically cache the files to be exported before exporting them all at once. This can quickly increase the browser's memory usage when exporting large files, causing the tab to freeze or crash, thus affecting the efficiency of exporting recording files. Summary of the Invention
[0003] The purpose of this application is to provide a method, apparatus, electronic device, and storage medium for exporting audio recording files, so as to improve the efficiency of exporting audio recording files. The specific technical solution is as follows: In a first aspect of this application, a method for exporting audio recording files is provided, the method comprising: In response to an export operation targeting a file, an export pre-check request is sent to the server to obtain the pull data corresponding to the target file and generate a persistent export list. The pull data includes at least the export task identifier, the total number of bytes in the target file, the number of bytes in the audio recording segments, the number of audio recording segments, the checksum, and the address for obtaining the audio recording segments. Obtain the target file path input by the user, establish the binding relationship between the target file path and the export task, and generate a persistent file handle for the target file path; The persistent file handle, the export list, and the task status are stored in the IndexedDB database; Upon receiving an instruction to export an audio file for the target file, the persistent file handle is retrieved from the IndexedDB database, and permission checks are performed on the persistent file handle. If the permission status indicates that authorization is not granted, initiate a user authorization request to obtain user authorization; When the permission status indicates an authorized status, create or restore a writable stream of the target exported file based on the persistent file handle; If an unprocessed recording segment is obtained, the file pointer is moved to the starting offset of the unprocessed recording segment, the recording segment is streamed into the target file corresponding to the target file path, and the processing status and cursor of the recording segment are updated, wherein the cursor is the index of the largest recording segment that has been processed.
[0004] In one possible implementation, the starting offset is calculated through the following steps: Obtain the total number of bytes in the target exported file and the number of bytes in each audio recording segment; For each recording segment, the starting offset corresponding to the recording segment is calculated based on the segment index of the recording segment, the total number of bytes in the target exported file, and the number of bytes in the recording segment.
[0005] In one possible implementation, the method further includes: Determine whether the current browser supports obtaining the audio recording segments from the background; wherein, the browser is used to provide an export page to the front end; If so, then continue acquiring the audio segments if the export page is detected to be closed; If not, upon detecting that the export page is closed, the task status of the export task is updated and stored in the IndexedDB database; wherein, the task status includes at least the processing status of each audio segment of the target exported file and the current cursor.
[0006] In one possible implementation, after detecting that the export page is closed, the method further includes storing the task status of the export task in the IndexedDB database: If the export recovery page is detected to be open, the task status of the export task is obtained from the IndexedDB database; wherein the export recovery page and the export page are from the same source page; Restore the writable stream of the target exported file based on the task status.
[0007] In one possible implementation, the method further includes: During the writing of the audio recording segments, if the gateway status information indicates a network interruption, the task status is updated and stored in the IndexedDB database. If the gateway status information indicates a network connection, the writable stream of the target exported file is restored based on the task status.
[0008] In one possible implementation, the method further includes: If the unprocessed audio segment is not identified, the target written file is verified based on the total number of bytes of the target exported file and the verification digest; If the verification passes, the task status is updated to complete and a notification message is generated.
[0009] In one possible implementation, before acquiring unprocessed audio segments, the method further includes: Determine if there are any unprocessed audio segments; If so, select and request a data stream of one of the unprocessed recording segments; Determine whether the data stream request was successful; If so, it is considered that the unprocessed audio segment has been obtained; If not, record the number of failures and the backoff time, and return to the step: determine if there are any unprocessed audio segments.
[0010] In a second aspect of this application, an audio recording file export apparatus is provided, the apparatus comprising: The export manifest generation module is used to send an export pre-inspection request to the server in response to an export operation for a target export file, to obtain the pull data corresponding to the target export file, and generate a persistent export manifest; wherein, the pull data includes at least the export task identifier, the total number of bytes of the target export file, the number of bytes of the recording segment, the number of recording segments, the verification digest, and the acquisition address of the recording segment; The file handle generation module is used to obtain the target file path input by the user, establish the binding relationship between the target file path and the export task, and generate a persistent file handle for the target file path. A persistent storage module is used to store the persistent file handle, the export list, and the task status in the IndexedDB database; The permission detection module is used to obtain the persistent file handle from the IndexedDB database and perform permission detection on the persistent file handle when it receives an instruction to export the audio file for the target export file. The permission acquisition module is used to initiate a user authorization request to obtain user authorization when the permission status indicates that the user is not authorized. The writable stream creation and restoration module is used to create or restore the writable stream of the target exported file based on the persistent file handle when the permission status indicates an authorized status. The recording segment writing module is used to move the file pointer to the starting offset of the unprocessed recording segment when an unprocessed recording segment is obtained, and to stream the recording segment to the target file corresponding to the target file path, and update the processing status and cursor of the recording segment, wherein the cursor is the index of the largest recording segment that has been processed.
[0011] In one possible implementation, the device further includes: The starting offset calculation module is used to obtain the total number of bytes in the target exported file and the number of bytes in the recording segments; for each recording segment, the starting offset corresponding to the recording segment is calculated based on the segment index of the recording segment, the order of the recording segment in the recording segments, the total number of bytes in the target exported file, and the number of bytes in the recording segment.
[0012] In one possible implementation, the device further includes: The backend acquisition capability judgment module is used to determine whether the current browser supports backend acquisition of the audio segments; wherein, the browser is used to provide an export page to the frontend; The audio segment background input module is used to continue acquiring the audio segments if the export page is closed. The task status saving module is used to update the task status of the export task and store it in the IndexedDB database if the export page is closed, unless otherwise specified. The task status includes at least the processing status of each audio segment of the target export file and the current cursor.
[0013] In one possible implementation, the device further includes: The writable stream recovery module is used to obtain the task status of the export task from the IndexedDB database when the export recovery page is detected to be open; wherein the export recovery page and the export page are from the same source page; and to recover the writable stream of the target exported file according to the task status.
[0014] In one possible implementation, the device further includes: The network interruption handling module is used to update the task status and store it in the IndexedDB database if the gateway status information indicates a network interruption during the writing process of the recording segment; and to restore the writable stream of the target exported file according to the task status if the gateway status information indicates a network connection.
[0015] In one possible implementation, the device further includes: The file verification module is used to verify the target written file based on the total number of bytes of the target exported file and the verification digest when no unprocessed audio segment is identified; if the verification passes, the task status is updated to complete and a notification message is generated.
[0016] In one possible implementation, the device further includes: The audio segment acquisition module is used to determine whether there are any unprocessed audio segments; if so, it selects and requests a data stream of the unprocessed audio segment; it determines whether the data stream request is successful; if so, it considers that the unprocessed audio segment has been acquired; if not, it records the number of failures and the backoff time, and returns to the step: determining whether there are any unprocessed audio segments.
[0017] In a third aspect of this application, an electronic device is provided, comprising: Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the method described in the first aspect of the embodiments of this application.
[0018] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein a computer program is stored therein, and the computer program, when executed by a processor, implements the method described in the first aspect of the present application.
[0019] Compared with the prior art, the embodiments of this application have at least the following technical effects: This application provides a method, apparatus, electronic device, and storage medium for exporting audio files. In response to an export operation targeting a file, an export pre-check request is sent to a server to obtain the pull data corresponding to the target file and generate a persistent export list. The pull data includes at least an export task identifier, the total number of bytes in the target file, the number of bytes in each audio segment, the number of audio segments, a checksum, and the address for obtaining the audio segments. The application also obtains the target file path input by the user, establishes a binding relationship between the target file path and the export task, and generates a persistent file handle for the target file path. The persistent file handle, the export list, and the task status are stored in an IndexedDB database. Upon receiving... When an instruction to export an audio file for the target exported file is executed, the persistent file handle is retrieved from the IndexedDB database, and permission checks are performed on the persistent file handle. If the permission status indicates unauthorized, a user authorization request is initiated to obtain user authorization. If the permission status indicates authorized, a writable stream for the target exported file is created or restored based on the persistent file handle. If an unprocessed audio segment is found, the file pointer is moved to the starting offset of the unprocessed audio segment, and the audio segment is streamed into the target file corresponding to the target file path. The processing status and cursor of the audio segment are updated, wherein the cursor is the index of the largest audio segment that has been processed.
[0020] The method described in this application establishes a binding relationship between the target file path and the export task, and persists the generated file handle to the IndexedDB database. During permission checks when writing files, only the file handle needs to be retrieved from the database for detection, and permissions are activated as needed (i.e., the permission status indicates unauthorized). This separates the processing of "target export file binding" and "current writability," avoiding the need for users to re-authorize and select the target file path when resuming after an interruption. This reduces the user burden, minimizes duplicate files, overwrite errors, or inconsistent archive locations, and improves the export efficiency of the target file. Furthermore, by dividing the target export file into multiple audio segments and streaming these segments according to their starting offsets, the browser does not need to store the complete file for an extended period. Instead, it continuously writes the data arriving in batches to the target file, ensuring that large files can be stably written to disk with low memory usage, improving the export efficiency of the target file, and enhancing overall throughput efficiency in weak network and multi-connection scenarios.
[0021] Of course, implementing any method of the embodiments of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description
[0022] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings.
[0023] Figure 1 A flowchart illustrating a method for exporting audio files provided in an embodiment of this application; Figure 2 A timing diagram for file handle authorization detection and task initialization provided for embodiments of this application; Figure 3 A flowchart illustrating the execution of an export task provided in an embodiment of this application; Figure 4 A schematic diagram of the structure of the audio recording file export device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.
[0025] In web applications such as call center quality inspection platforms, monitoring recording archiving platforms, and enterprise-level compliance audit systems, administrators often need to export massive amounts of recordings in batches and generate local compressed packages or equivalent archive files, with single export volumes reaching several GB or even over 10 GB. The applicant found that browser-based export solutions in related technologies typically face the following problems: 1. Export methods based on memory aggregation are prone to triggering OOM (Out of Memory): The traditional method of assembling (Binary Large Object) blobs, caching them in memory, and then downloading them all at once, or caching all fragments in RAM (Random Access Memory) on the front end and then exporting them all at once, will quickly push up the browser's memory peak as the export size increases, causing the tab to freeze or crash.
[0026] 2. Vulnerability of single-connection downloads: When using single-connection or full-packet download mode for very large files, network jitter, gateway timeout, VPN (Virtual Private Network) disconnection and other anomalies can easily cause task failure and force users to export from the beginning again.
[0027] 3. Task status is usually strongly bound to the current page: Many front-end export implementations retain the fragment progress, target file path, and current offset only in the memory of the page that initiated the export. Once the page is refreshed, closed, or the browser is restarted, the front-end cannot accurately know which bytes have been safely written to disk and which fragments still need to be retried.
[0028] 4. Disjointed Local Save Authorization and Resume Process: Browser write permissions for local files typically rely on explicit user authorization. Existing solutions often require users to reselect the save path after an export is interrupted, which increases the operational burden and is prone to causing duplicate files, overwriting errors, or inconsistent archive locations.
[0029] To address at least one of the aforementioned problems, in a first aspect of this application, a method for exporting audio recording files is provided, characterized in that the method includes as follows: Figure 1 The steps shown are as follows: Step S101: In response to the export operation for the target export file, send an export pre-check request to the server to obtain the pull data corresponding to the target export file and generate a persistent export list.
[0030] In practical applications, the front-end provides a display interface to the user, offering interactive operations such as browsing, downloading, archiving, and exporting. Users can select the desired function through touch, typing, or mouse operation. For example, a user can trigger an export preflight request by clicking the "Export Monthly Audio Archive" button on the front-end page. At this point, the front-end sends an export preflight request to the server to retrieve the data.
[0031] The data retrieved includes at least the export task identifier, the total number of bytes in the target export file, the number of bytes in the audio recording segments, the number of audio recording segments, the verification digest, and the address for obtaining the audio recording segments.
[0032] The export task identifier can be the export task's ID (Identifier). In one example, the export task identifier can be written into the taskId (task identifier) field. In practical applications, the target export file is the audio file determined by the user through the export operation. This audio file can be divided into multiple audio segments, and the segmentation method can be time window segmentation, silence detection segmentation, semantic awareness segmentation, etc.
[0033] In one example, for the target exported file, an independent audio block can be generated every 10 seconds as a recording segment. In another example, a semantically complete audio segment can be used as a recording segment through silence detection or semantic recognition. The number of recording segments can be determined by first segmenting the file using either of the above methods and then obtaining the number of recording segments, or by pre-setting the number according to business requirements and then dividing the target exported file according to that number to obtain the recording segments.
[0034] The verification digest is a file-level hash value used to verify whether the target exported file has undergone bit-level tampering or corruption due to transmission, storage, or editing; that is, a file integrity verification value generated by a hash algorithm. The audio segment retrieval address refers to the address where the audio segment can be obtained. In one example, this retrieval address could be a front-end memory reference address, a cloud download link, or a local file path. In practical applications, the export manifest can also include other equivalent fetched data, such as file length, audio segment index, and byte boundaries of each audio segment.
[0035] Step S102: Obtain the target file path input by the user, establish the binding relationship between the target file path and the export task, and generate a persistent file handle for the target file path.
[0036] In practical applications, the target file path input by the user can be obtained by calling `showSaveFilePicker` (a file save dialog box) or an equivalent file selection interface. Specifically, in this embodiment, the front end can display a file save dialog box on the page, where the user selects the target file path, thus obtaining the user-input target file path. The target file path is the path pointing to the target file to be written; for example, the target file path is the path where the target file to be written can be obtained. The target file to be written is the file that writes and saves the target exported file; for example, when the user downloads a file, the file to be saved is the target file to be written, and the file to be downloaded is the target exported file.
[0037] Binding the target file path to the export task yields a persistent file handle (FileSystemFileHandle, a handle object pointing to a specific local file, which can be used to query permissions, request permissions, and create writable streams) corresponding to the export task. In one example, binding the target file path to the export task can involve establishing a mapping between the export task identifier and the target file path, thus achieving the binding between the target file path and the export task.
[0038] Step S103: Store the persistent file handle, export list, and task status in the IndexedDB database.
[0039] The file handle, export list, and task status are all persistently stored in the IndexedDB database. The task status represents the processing status of the export task, such as whether the task has not started, is in progress, is completed, or has failed; it can also include the processing status of each audio segment of the target exported file. In practical applications, the task status can also include metadata such as the current cursor, the set of processed audio segments, the number of retries for failed exports, the most recent disk write offset, notification status, and notification configuration.
[0040] The cursor is the index of the largest recorded segment that has been processed so far, and the most recent write offset is the offset of the file pointer most recently. The notification status confirms whether an event message has been delivered to the target endpoint. This event message can be a notification message generated by the system after the target file has been exported, and may include metadata such as event type, operation object, timestamp, and operation result status. The target endpoint is the destination or service that receives and processes the aforementioned event message. Notification configuration refers to predefined declarative event triggering rules that specify which event type should be pushed to which location.
[0041] Step S104: Upon receiving an instruction to export an audio file for the target file, obtain a persistent file handle from the IndexedDB database and perform permission checks on the persistent file handle.
[0042] The command to export audio files can also be triggered through user interaction on the front-end page. For example, a user could trigger the export command by clicking the "Download" button on the front-end page. Upon receiving the export command, the front-end page can send an export task message to the back-end coordination layer. The back-end coordination layer can then retrieve the persistent file handle from the IndexedDB (IndexedDatabase) database based on the task identifier and the binding relationship between the target file path and the export task.
[0043] When performing permission checks on persistent file handles, this can be done by executing `queryPermission({mode: 'readwrite'})` (a call to request read and write permissions) or equivalent permission checks. When exporting the target file, read and write permissions for the file are required to read and write the corresponding audio segments.
[0044] Step S105: If the permission status indicates that authorization is not granted, initiate a user authorization request to obtain user authorization.
[0045] In one example, if the permission status indicates unauthorized, the backend coordination layer (referring to the execution logic used to schedule export tasks between frontend pages, worker threads, Service Workers, and other backend capabilities) can send an activation request (i.e., a user authorization request) to any controlled frontend page with the same origin. When triggered by user interaction, requestPermission({ mode:'readwrite'}) (actively confirming whether the user has authorized the site to use read and write storage permissions before writing data) or an equivalent capability can be called to reactivate write permissions.
[0046] Step S106: If the permission status indicates an authorized status, create or restore a writable stream of the target exported file based on the persistent file handle.
[0047] In practical applications, the number of times the export task corresponding to the target exported file has been executed can also be determined through task status data. If it is the first execution, a writable stream for the target exported file is created; if it is not the first execution, the writable stream for the target exported file is restored to enable writing to disk for the target exported file. In one example, a FileSystemWritableFileStream (a writable data stream for local files (i.e., the target write file), supporting operations such as seek(), write(), and close()) can be created using FileSystemFileHandle.
[0048] Step S107: If an unprocessed recording segment is obtained, move the file pointer to the starting offset of the unprocessed recording segment, stream the recording segment to the target file corresponding to the target file path, and update the processing status and cursor of the recording segment.
[0049] The cursor is the index of the largest recording segment that has been processed or an equivalent progress indicator, which can be used to resume the remaining export work.
[0050] The method described in this application establishes a binding relationship between the target file path and the export task, and persists the generated file handle to the IndexedDB database. During permission checks when writing files, only the file handle needs to be retrieved from the database for detection, and permissions are activated as needed (i.e., the permission status indicates unauthorized). This separates the processing of "target export file binding" and "current writability," avoiding the need for users to re-authorize and select the target file path when resuming after an interruption. This reduces the user burden, minimizes duplicate files, overwrite errors, or inconsistent archive locations, and improves the export efficiency of the target file. Furthermore, by dividing the target export file into multiple audio segments and streaming these segments according to their starting offsets, the browser does not need to store the complete file for an extended period. Instead, it continuously writes the data arriving in batches to the target file, ensuring that large files can be stably written to disk with low memory usage, improving the export efficiency of the target file, and enhancing overall throughput efficiency in weak network and multi-connection scenarios.
[0051] In one possible implementation, the initial offset is calculated through the following steps: Step 1: Obtain the total number of bytes in the target exported file and the number of bytes in the audio recording segments.
[0052] Step 2: For each recording segment, calculate the starting offset corresponding to that recording segment based on its segment index, the total number of bytes in the target exported file, and the number of bytes in the recording segment.
[0053] In one example, the starting offset of a recording segment can be calculated using the following formula: ; in, This represents the starting offset of the i-th recording segment, where i represents the segment index and C is the size of the recording segment in bytes.
[0054] The size of each audio recording segment can be determined based on the total size of the target exported file and the number of audio recording segments. In one example, the total size of the target exported file is S_total; the number of audio recording segments is n. Then C can be determined using S_total. n obtains.
[0055] By applying the method of this application embodiment, the target exported file is divided into multiple audio recording segments, and the audio recording segments are streamed according to the starting offset. This allows the browser to write the data arriving in batches to the target file continuously without having to save the complete file for a long time. This ensures that large files can be stably written to disk in a low-memory manner, improves the export efficiency of the target exported file, and enhances the overall throughput efficiency in weak network and multi-connection scenarios.
[0056] In one possible implementation, the method of this application embodiment may further include the following steps: Step 1: Determine if the current browser supports retrieving audio segments in the background. If yes, proceed to Step 2; otherwise, proceed to Step 3.
[0057] Step 2: If the export page is detected as closed, continue to acquire audio segments.
[0058] Step 3: If the export page is detected to be closed, update the task status of the export task and store it in the IndexedDB database.
[0059] The browser is used to provide the export page to the front end. The task status includes at least the processing status of each audio segment of the target export file and the current cursor position. In one example, the browser's background fetch capability can be determined using methods such as Background Fetch API (Background Fetch Application Programming Interface), Background Sync API (Background Synchronization API), and Periodic Background Sync API (Periodic Background Synchronization API).
[0060] When the browser supports background fetching, Service Worker or Background Fetch can take over the network fetching phase when the exported page is closed, allowing the task to continue or wait for resumption after the page is closed. When the browser does not support background fetching, the system does not discard the task, but keeps its task status at paused, waiting_for_permission, or equivalent, and stores it in the IndexedDB database.
[0061] In one example, such as Figure 2 The diagram shows the sequence of file handle authorization detection and task initialization in this application. After the user performs the export operation on the target file (e.g., clicking "Export Monthly Recording Archive"), the front-end page sends an export pre-inspection request to the server. The server returns the retrieved data (taskId, totalSize (total size of the target exported file in bytes), chunkManifest (chunk list)) to the front-end page. showSaveFilePicker() is called to obtain the target file path selected by the user (i.e., the save path where the target exported file is stored in the target written file), and then a persistent file handle is generated. The front-end page stores the persistent file handle, export list, and task status, among other task metadata, in the IndexedDB database. The front-end page sends a message to the back-end coordination layer to start the export task, and the back-end coordination layer writes the task status as pending. When processing the export task, determine whether the current browser supports background fetching. If so, register the background fetching task via ServiceWorker or Background Fetch and send back the recording segment completion event. If not, continuously execute the start recording segment request and disk writing loop on the current page or worker thread to achieve reading and writing of recording segments. If the page is closed or the network is interrupted, the current task state can be preserved, and the user can be notified on the front-end page that the task has been persisted and can be resumed later.
[0062] By applying the method of this application embodiment, the background fetching capability of the browser is determined. Browsers with background fetching capability can take over the network fetching stage through Service Worker or BackgroundFetch after the export page is closed, and continue to acquire and write audio segments. Browsers without background fetching capability will also update the current task state after the export page is closed, and persist it in the IndexedDB database. This makes "page closing" no longer equivalent to "loss of export context". Even if a certain execution context terminates, the export task can be migrated to a new executable context in a state machine manner, thereby improving the export efficiency of audio files.
[0063] In one possible implementation, after detecting that the export page is closed and storing the task status of the export task in the IndexedDB database, the method of this application embodiment may further include the following steps: Step A: If the export recovery page is detected to be open, retrieve the task status of the export task from the IndexedDB database.
[0064] Step B: Restore the writable stream of the target exported file based on the task status.
[0065] In this context, the export recovery page and the export page are considered to be from the same origin. For example, if a page shares the same protocol, host, and port as the export page, it is considered an export recovery page from the same origin. When resuming an export task, the remaining audio segment set, the current cursor, and persistent file handle can be retrieved from the IndexedDB database to continue the export process and export the target file.
[0066] In one possible implementation, the method of this application embodiment may further include the following steps: Step a: During the writing of audio segments, if the gateway status information indicates a network interruption, the task status will be updated and stored in the IndexedDB database.
[0067] Step b: If the gateway status information indicates a network connection, restore the writable stream of the target exported file according to the task status.
[0068] In practical applications, when the network is interrupted, the system can persistently record failed recording segments, completed recording segments, and the current cursor in the IndexedDB database. This allows the system to resume the writable stream of the target exported file according to the task progress at the time of the network interruption when the network is restored. For example, if the network interrupts when the download progress is 60%, and the 181st recording segment is being written, the system should record the failed recording segments, completed recording segments, and the current cursor status. When the network is restored, the task status can be read through the background coordination layer or the export recovery page, and fetching and writing can resume from the 181st recording segment without starting from scratch.
[0069] By applying the method of this application embodiment, updating and saving the task status when the network is interrupted can avoid having to start exporting the target file from scratch when the task fails due to network interruption. The export process can be resumed only by retrieving the task status data from the database when the network is restored, thereby improving the export efficiency of audio files.
[0070] In one possible implementation, the method of this application embodiment may further include the following steps: Step (1): If no unprocessed audio segments are identified, verify the target file to be written based on the total number of bytes in the target exported file and the checksum.
[0071] Step (2): If the verification passes, update the task status to complete and generate a notification message.
[0072] In one example, a checksum can be used to determine whether the target exported file was modified or corrupted during the writing process to the target written file. If so, the checksum fails; otherwise, it passes. In another example, it can be determined whether the total number of bytes in the target written file is the same as the total number of bytes in the target exported file. If so, the checksum passes; otherwise, it fails.
[0073] The notification message is used to inform the user that the export task has been completed. It can be displayed in a preset position on the front-end page or as a pop-up window.
[0074] By applying the method of this application embodiment, the target written file is verified based on the total number of bytes of the target exported file and the checksum, which can ensure the accuracy of the exported recording file, avoid the export of corrupted files, and thus improve the export efficiency of the recording file.
[0075] In one possible implementation, the method of this application embodiment may further include the following steps: Step (a): Determine if there are any unprocessed audio segments; if yes, proceed to step (b); if no, proceed to steps (1)-(2) above.
[0076] Step (b): Select and request a data stream of an unprocessed audio segment.
[0077] Step (c): Determine whether the data stream request was successful; if yes, it is considered that the unprocessed audio segment has been obtained; if not, proceed to step (d).
[0078] Step (d): Record the number of failures and the backoff time, then return to step (a).
[0079] When requesting unprocessed audio segments, the request can be random, sequential, or ordered by the size of the audio segment in ascending or descending order of bytes. Another example is out-of-order reading and writing of audio segments based on offsets. In practical applications, the backend coordination layer can initiate multiple concurrent segment requests to simultaneously acquire multiple audio segments for reading and writing operations, and then perform fill-in writing of audio segments after the concurrent operations are completed.
[0080] In practical applications, a failure count threshold can also be set. If the recorded failure count reaches this threshold, an alarm message can be generated to provide a notification. The backoff time is the system waiting time. To prevent channel conflicts, the system will pause the acquisition of recording segments within this time range. After the backoff time ends, it will return to step (a) to continue the acquisition of recording segments.
[0081] In one example, it can be done by Figure 3 The process shown implements the reading and writing of audio recording segments. When executing the export task, the task and cursor in the IndexedDB database are read first to obtain the file handle. It is then determined whether the current file handle is writable (permission check). If it is, a writable stream is created or restored; otherwise, the front-end page is notified to reactivate write permissions. If permission restoration is successful, a writable stream is created or restored; if permission restoration fails, the task is paused and the current task state is retained.
[0082] During the reading and writing of audio segments, first determine if there are any incomplete audio segments. If so, select an audio segment N to be processed and request the data stream of audio segment N. If the request is successful, seek (position) to the starting offset of audio segment N, stream the data stream of audio segment N to the local target file, and update the processing status and current cursor of audio segment N.
[0083] If requesting a data stream for a recording segment fails, the number of failures and the backoff time are recorded. After the backoff time expires, the process returns to check if there are any incomplete recording segments. If there are no incomplete recording segments, the total number of bytes and the digest are checked, a completion status is written, and the user is notified.
[0084] By applying the method of the embodiments of this application, the target exported file is divided into multiple audio segments, and the audio segments are streamed according to the starting offset. This allows the browser to write the data arriving in batches to the target file continuously without having to save the complete file for a long time. This ensures that large files can be stably written to disk with low memory usage, improves the export efficiency of the target exported file, and enhances the overall throughput efficiency in weak network and multi-connection scenarios.
[0085] The following example illustrates the method for exporting audio recordings in this application. Suppose a call center user needs to export all recordings of inappropriate calls for a certain month into a ZIP archive of approximately 15GB for local offline auditing. The exported file is generated on demand by the server and provided to the front end in 300 logical chunks, each approximately 50MB. The export can be performed as follows: First, the user clicks "Export Monthly Archive" on the front-end page, triggering the export operation. The front-end then sends an export pre-check request to the server. The server returns the task identifier (taskId), the total number of bytes in the target exported file, the number of bytes in each audio segment, the number of audio segments, the checksum, and the address to retrieve the audio segments. Next, the front-end calls showSaveFilePicker to obtain the target file path for the file selected by the user. In one example, the target path for the file selected by the user is: D:\\Audit\\2026-02-records.zip.
[0086] Subsequently, the frontend writes the generated file handle, fragment list, initial cursor, task status, and notification configuration information to the IndexedDB database and notifies the backend coordination layer to take over the task. Upon receiving the task, the backend coordination layer obtains the file handle, performs permission checks, and, if authorized, initiates multiple concurrent fragment requests. Assuming fragment 2 completes acquisition first, the disk writing module calls `writable.seek(50MB)` to move the file pointer to the starting offset corresponding to recording fragment 2, and then writes the data stream of that recording fragment to the target file. During this process, only the fragment buffer currently being transmitted or written is retained in memory.
[0087] In addition, the method in this application embodiment can also determine the browser's background acquisition capability. If the user closes the export page during the export process of the target file, for browsers that support background acquisition capability, the system can continue to acquire and write the remaining recording allocation in the background; for browsers that do not support background acquisition capability, the current task status can be saved in the database and the export task can be automatically resumed when the user opens any same source page again.
[0088] Similarly, if a network interruption occurs during the export process of the target file, for example, when the download is about 60% complete, the system persistently records the task status data, including failed audio segments, completed audio segments, and the current cursor, and stores it in the IndexedDB database. Once the network is restored, the background coordination layer or the re-entered export recovery page (which shares the same origin as the export page) reads the task status data and continues fetching and writing audio segments starting from the 181st audio segment, without having to start from the beginning.
[0089] Finally, after all the recording segments have been written to the disk, the system verifies the total number of bytes in the target exported file against the checksum. If the verification passes, a message "2026-02-records.zip export complete" will pop up via the task center or system notification.
[0090] In one possible implementation, the server in this embodiment can directly send the compressed package of the target exported file to the front end, or it can choose not to generate the complete compressed package file in advance, but instead dynamically assemble the archive according to the export task logic and return the compressed package byte stream step by step according to the recording segmentation interface. The front end is only responsible for streaming reception and local disk writing. When the server only provides a list of recorded files, the front end can use fflate (fast flate) or an equivalent streaming compression engine in the worker thread to generate a ZIP directory structure and compressed data, and then directly write the generated result to the file handle.
[0091] In scenarios supporting the background fetch capabilities of corresponding browsers, this embodiment can further delegate the network fetch phase to Background Fetch or equivalent background download capabilities, and resume file writing to disk and state convergence after the completion event. For browsers that do not support the File System Access API, the system automatically reverts to server-side full package generation plus native download, desktop client-assisted export, or other controlled export modes, thereby enabling the system to accommodate multiple implementation methods and improve system compatibility. For scenarios such as supervision or auditing, the summary value can be recorded after each audio segment is written to disk, and an export verification report can be generated after the entire package is completed to enhance the traceability of exported files.
[0092] By persistently binding the target file path to the export task using the method of this application, the export path can be reselected when the export is interrupted, allowing the task to continue writing to the same target file when it resumes. Using seek() with an absolute offset for disk writing enables the browser to perform low-memory, out-of-order, recoverable local assembly of large archive files, thereby reducing the load on the user end. Furthermore, this application avoids storing the export progress in a single page's memory; instead, it uniformly stores multiple task metadata (file handles, export lists, task status data, etc.) in the IndexedDB database, allowing the front-end page, worker threads, and back-end to collaborate around the same task status. In addition, it allows Service Worker or Background Fetch to take over the network fetch phase when supported, and to revert to page or worker thread recovery mode when not supported, thus maintaining the core export state machine and disk writing mechanism unchanged.
[0093] In a second aspect of this application, an audio recording file export apparatus is provided, the apparatus comprising: Figure 4 The structure shown is as follows: The export list generation module 401 is used to send an export pre-inspection request to the server in response to an export operation for the target export file, so as to obtain the pull data corresponding to the target export file and generate a persistent export list; wherein, the pull data includes at least the export task identifier, the total number of bytes of the target export file, the number of bytes of the recording segment, the number of recording segments, the verification digest, and the acquisition address of the recording segment; The file handle generation module 402 is used to obtain the target file path input by the user, establish the binding relationship between the target file path and the export task, and generate a persistent file handle for the target file path. The persistent storage module 403 is used to store persistent file handles, export lists, and task status in the IndexedDB database; The permission detection module 404 is used to obtain a persistent file handle from the IndexedDB database and perform permission detection on the persistent file handle when it receives an instruction to export an audio file for the target export file. The permission acquisition module 405 is used to initiate a user authorization request to obtain user authorization when the permission status indicates that the user is not authorized. The writable stream creation and restoration module 406 is used to create or restore a writable stream of the target exported file based on the persistent file handle when the permission status indicates an authorized status. The recording segment writing module 407 is used to move the file pointer to the starting offset of the unprocessed recording segment when an unprocessed recording segment is obtained, stream write the recording segment to the target file corresponding to the target file path, and update the processing status and cursor of the recording segment, wherein the cursor is the index of the largest recording segment that has been processed.
[0094] In one possible implementation, the device further includes: The starting offset calculation module is used to obtain the total number of bytes in the target exported file and the number of bytes in the recording segments. For each recording segment, the starting offset corresponding to the recording segment is calculated based on the segment index of the recording segment, the order of the recording segment in the recording segments, the total number of bytes in the target exported file, and the number of bytes in the recording segment.
[0095] In one possible implementation, the device further includes: The backend retrieval capability judgment module is used to determine whether the current browser supports backend retrieval of audio segments; the browser is used to provide the export page to the frontend. The audio segment background input module is used to continue acquiring audio segments if the export page is closed. The task status saving module is used to update the task status of the export task and store it in the IndexedDB database if the export page is closed. The task status includes at least the processing status of each audio segment of the target export file and the current cursor.
[0096] In one possible implementation, the device further includes: The writable stream recovery module is used to retrieve the task status of the export task from the IndexedDB database when the export recovery page is detected to be open; the export recovery page and the export page are from the same source page; and the writable stream of the target exported file is recovered based on the task status.
[0097] In one possible implementation, the device further includes: The network interruption handling module is used to update the task status and store it in the IndexedDB database if the gateway status information indicates a network interruption during the writing of audio segments; if the gateway status information indicates a network connection, it restores the writable stream of the target exported file according to the task status.
[0098] In one possible implementation, the device further includes: The file verification module is used to verify the target file written to the target file based on the total number of bytes of the target exported file and the verification digest if no unprocessed audio segments are identified. If the verification passes, the task status is updated to complete and a notification message is generated.
[0099] In one possible implementation, the device further includes: The audio segment acquisition module is used to determine whether there are any unprocessed audio segments; if so, it selects and requests a data stream of an unprocessed audio segment; it determines whether the data stream request is successful; if so, it considers that the unprocessed audio segment has been acquired; if not, it records the number of failures and the backoff time, and returns to the step: determine whether there are any unprocessed audio segments.
[0100] In a third aspect of the embodiments of this application, an electronic device is provided, see [link to relevant documentation]. Figure 5 ,include: Memory 501 is used to store computer programs; Processor 502, when executing a program stored in memory, implements: In response to an export operation targeting a target file, an export pre-check request is sent to the server to obtain the pull data corresponding to the target file and generate a persistent export list. The pull data includes at least the export task identifier, the total number of bytes in the target file, the number of bytes in the audio recording segments, the number of audio recording segments, the checksum, and the address for obtaining the audio recording segments. Obtain the target file path input by the user, establish the binding relationship between the target file path and the export task, and generate a persistent file handle for the target file path; The persistent file handle, export list, and task status are stored in the IndexedDB database; When a recording file export instruction is received for the target export file, a persistent file handle is obtained from the IndexedDB database, and permission checks are performed on the persistent file handle. If the permission status indicates that authorization is not granted, initiate a user authorization request to obtain user authorization; When the permission status indicates an authorized status, create or restore a writable stream of the target exported file based on the persistent file handle; If an unprocessed recording segment is obtained, the file pointer is moved to the starting offset of the unprocessed recording segment, the recording segment is streamed into the target file corresponding to the target file path, and the processing status and cursor of the recording segment are updated. The cursor is the index of the largest recording segment that has been processed.
[0101] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.
[0102] The communication interface is used for communication between the aforementioned electronic devices and other devices.
[0103] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.
[0104] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0105] In a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when the computer program is executed by a processor, it implements the method of the first aspect of the embodiments of this application.
[0106] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to implement the method of the first aspect of the embodiments of this application.
[0107] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.
[0108] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0109] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. Related parts can be found in the descriptions of the system embodiments.
[0110] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.
Claims
1. A method for exporting audio recording files, characterized in that, The method includes: In response to an export operation targeting a file, an export pre-check request is sent to the server to obtain the pull data corresponding to the target file and generate a persistent export list. The pull data includes at least the export task identifier, the total number of bytes in the target file, the number of bytes in the audio recording segments, the number of audio recording segments, the checksum, and the address for obtaining the audio recording segments. Obtain the target file path input by the user, establish the binding relationship between the target file path and the export task, and generate a persistent file handle for the target file path; The persistent file handle, the export list, and the task status are stored in the IndexedDB database; Upon receiving an instruction to export an audio file for the target file, the persistent file handle is retrieved from the IndexedDB database, and permission checks are performed on the persistent file handle. If the permission status indicates that authorization is not granted, initiate a user authorization request to obtain user authorization; When the permission status indicates an authorized status, create or restore a writable stream of the target exported file based on the persistent file handle; If an unprocessed recording segment is obtained, the file pointer is moved to the starting offset of the unprocessed recording segment, the recording segment is streamed into the target file corresponding to the target file path, and the processing status and cursor of the recording segment are updated, wherein the cursor is the index of the largest recording segment that has been processed.
2. The method according to claim 1, characterized in that, The initial offset is calculated through the following steps: Obtain the total number of bytes in the target exported file and the number of bytes in each audio recording segment; For each recording segment, the starting offset corresponding to the recording segment is calculated based on the segment index of the recording segment, the total number of bytes in the target exported file, and the number of bytes in the recording segment.
3. The method according to claim 1, characterized in that, The method further includes: Determine whether the current browser supports obtaining the audio recording segments from the background; wherein, the browser is used to provide an export page to the front end; If so, then continue acquiring the audio segments if the export page is detected to be closed; If not, upon detecting that the export page is closed, the task status of the export task is updated and stored in the IndexedDB database; wherein, the task status includes at least the processing status of each audio segment of the target exported file and the current cursor.
4. The method according to claim 3, characterized in that, After detecting that the export page is closed, and storing the task status of the export task in the IndexedDB database, the method further includes: If the export recovery page is detected to be open, the task status of the export task is obtained from the IndexedDB database; wherein the export recovery page and the export page are from the same source page; Restore the writable stream of the target exported file based on the task status.
5. The method according to claim 3, characterized in that, The method further includes: During the writing of the audio recording segments, if the gateway status information indicates a network interruption, the task status is updated and stored in the IndexedDB database. If the gateway status information indicates a network connection, the writable stream of the target exported file is restored based on the task status.
6. The method according to claim 1, characterized in that, The method further includes: If the unprocessed audio segment is not identified, the target written file is verified based on the total number of bytes of the target exported file and the verification digest; If the verification passes, the task status is updated to complete and a notification message is generated.
7. The method according to claim 1, characterized in that, Before acquiring unprocessed audio segments, the method further includes: Determine if there are any unprocessed audio segments; If so, select and request a data stream of one of the unprocessed recording segments; Determine whether the data stream request was successful; If so, it is considered that the unprocessed audio segment has been obtained; If not, record the number of failures and the backoff time, and return to the step: determine if there are any unprocessed audio segments.
8. A device for exporting audio recordings, characterized in that, The device includes: In response to an export operation targeting a file, an export pre-check request is sent to the server to obtain the pull data corresponding to the target file and generate a persistent export list. The pull data includes at least the export task identifier, the total number of bytes in the target file, the number of bytes in the audio recording segments, the number of audio recording segments, the checksum, and the address for obtaining the audio recording segments. Obtain the target file path input by the user, establish the binding relationship between the target file path and the export task, and generate a persistent file handle for the target file path; The persistent file handle, the export list, and the task status are stored in the IndexedDB database; Upon receiving an instruction to export an audio file for the target file, the persistent file handle is retrieved from the IndexedDB database, and permission checks are performed on the persistent file handle. If the permission status indicates that authorization is not granted, initiate a user authorization request to obtain user authorization; When the permission status indicates an authorized status, create or restore a writable stream of the target exported file based on the persistent file handle; If an unprocessed recording segment is obtained, the file pointer is moved to the starting offset of the unprocessed recording segment, the recording segment is streamed into the target file corresponding to the target file path, and the processing status and cursor of the recording segment are updated, wherein the cursor is the index of the largest recording segment that has been processed.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains a computer program that, when executed by a processor, implements the method described in claims 1-7.