Method, device and equipment for restoring recording data, and storage medium

Abstract

The application discloses a kind of recovery method, device and equipment of recording data and storage medium, belong to application software field.The method comprises: the tuning interface of application program is displayed;The first recording and first group tuning parameters are displayed in the tuning interface;The first group tuning parameters is according to the tuning operation of adjusting the first recording and is displayed;Under the condition of displaying the tuning interface, the first recording and the first group tuning parameters are cached to cache area;In response to the application program abnormal exit and start again, the tuning interface is recovered;The first recording and the first group tuning parameters are displayed in the tuning interface;The first group tuning parameters are identical with the tuning parameters displayed on the tuning interface before abnormal exit.The method can avoid the tuning record loss of recording after application program abnormal exit.

Description

Technical Field

[0001] This application relates to the field of application software, and in particular to a method, apparatus, device, and storage medium for recovering audio recording data. Background Technology

[0002] With the development of mobile internet and smart terminals, karaoke apps have become an important platform for users to record and enjoy audio entertainment. The audio editing interface of karaoke apps is used to edit and adjust the original audio after recording. In the audio editing interface, users can adjust parameters such as vocal volume, accompaniment volume, vocal alignment, and sound effects to enhance the vocals, optimize the listening experience, and ultimately obtain a satisfactory personal recording.

[0003] In related technologies, the recording data and tuning parameters within the tuning interface rely on manual saving by the user. The application will only execute the recording storage process after the user actively clicks to save the recording.

[0004] However, if an abnormal exit occurs, such as an application crash, the user accidentally closing a background process, or the operating system forcibly terminating the process due to insufficient resources, all the editing work done by the user in the tuning interface will be lost, and the user will need to restart the application to record and tune again. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for recovering audio recording data, which can prevent the loss of audio tuning records after an application exits abnormally. The technical solution is as follows: According to one aspect of this application, a method for recovering audio recording data is provided, the method comprising: The application displays a tuning interface; the tuning interface displays a first recording and a first set of tuning parameters; the first set of tuning parameters is displayed based on the tuning operation performed on the first recording; When the tuning interface is displayed, the first recording and the first set of tuning parameters are cached in the buffer area; In response to the application's abnormal exit and subsequent restart, the tuning interface is restored; the tuning interface displays the first recording and the first set of tuning parameters; the first set of tuning parameters is the same as the tuning parameters displayed on the tuning interface before the abnormal exit.

[0006] According to another aspect of this application, a device for recovering audio recording data is provided, the device comprising: The display module is used to display the tuning interface of the application; the tuning interface displays a first recording and a first set of tuning parameters; the first set of tuning parameters is displayed based on the tuning operation of adjusting the first recording; The caching module is used to cache the first recording and the first set of tuning parameters to the cache area when the tuning interface is displayed; A recovery module is used to restore the tuning interface in response to the application's abnormal exit and restart; the tuning interface displays the first recording and the first set of tuning parameters; the first set of tuning parameters is the same as the tuning parameters displayed on the tuning interface before the abnormal exit.

[0007] According to another aspect of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, the at least one program, the code set or instruction set being loaded and executed by the processor to implement the method for recovering recording data as described above.

[0008] According to another aspect of this application, a computer-readable storage medium is provided, wherein at least one instruction, at least one program, code set, or instruction set is stored therein, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the method for recovering recording data as described above.

[0009] According to another aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the recording data recovery method provided in various optional implementations of the above aspects.

[0010] The beneficial effects of the technical solution provided in this application include at least the following: When the application displays the tuning interface, the recordings and tuning parameters on the tuning page are cached. If the application crashes, the tuning interface is restored upon the next launch based on the cached recordings and tuning parameters, ensuring that the restored tuning interface is identical to the one displayed before the crash. This allows users to directly return to their previous editing state after the application crashes and restarts, preventing data loss due to unexpected interruptions. Furthermore, this method requires no manual user intervention; the application can automatically perform data caching and interface restoration, reducing user workload. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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 without creative effort.

[0012] Figure 1 This is a schematic diagram of the structure of a computer system provided in an exemplary embodiment of this application; Figure 2 This is a flowchart of a method for recovering audio recording data provided in an exemplary embodiment of this application; Figure 3 This is a flowchart of a method for recovering audio recording data provided in an exemplary embodiment of this application; Figure 4 This is a flowchart of a method for recovering audio recording data provided in an exemplary embodiment of this application; Figure 5 This is a flowchart of a method for recovering audio recording data provided in an exemplary embodiment of this application; Figure 6 This is a schematic diagram of a method for recovering audio recording data provided in an exemplary embodiment of this application; Figure 7 This is a schematic diagram of the structure of a recording data recovery device provided in an exemplary embodiment of this application; Figure 8 This is a schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application.

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0015] Figure 1 A schematic diagram of a computer system provided in an exemplary embodiment of this application is shown. The computer system may include a terminal device 101 and a server 103.

[0016] For example, the method for recovering audio recording data shown in this application embodiment can be applied to a terminal device 101, which runs an application 102 that supports recording. The terminal device may include a mobile phone, tablet computer, laptop computer, desktop computer, all-in-one computer, Internet of Things device, smart robot workstation, television, set-top box, smart glasses, smartwatch, digital camera, MP4 playback device, MP5 playback device, learning machine, e-reader, e-book, electronic dictionary, in-vehicle device, virtual reality (VR) playback device or augmented reality (AR) playback device, etc.

[0017] For example, the method for recovering audio recording data provided in this application can be executed by a client in a terminal device. This client is a client of an application that supports recording. Any application with recording functionality can apply the method for recovering audio recording data provided in this application embodiment; therefore, this application is not limited to the type of application. For example, the application may include at least one of the following: audio application, video application, short video application, social application, shopping application, live streaming application, news application, browser, local service application, travel application, and financial application.

[0018] Terminal device 101 includes a first memory and a first processor. The first memory stores a program for recovering recorded data; the program for recovering recorded data is invoked and executed by the first processor to implement the method for recovering recorded data provided in this application. The first memory may include, but is not limited to, the following: Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM).

[0019] The first processor can consist of one or more integrated circuit chips. Optionally, the first processor can be a general-purpose processor, such as a central processing unit (CPU) or a network processor (NP). Optionally, the first processor can implement the recording data recovery method provided in this application by running programs or code.

[0020] In one alternative embodiment, the terminal device 101 and the server 103 can be interconnected via a wired or wireless network.

[0021] Server 103 is used to provide background services for the client of terminal device 101. Optionally, server 103 undertakes the main computing work and terminal device 101 undertakes the secondary computing work; or, server 103 undertakes the secondary computing work and terminal device 101 undertakes the main computing work; or, server 103 and terminal device 101 use a distributed computing architecture for collaborative computing.

[0022] Server 103 can be a single server, a server cluster consisting of multiple servers, or a cloud computing service center.

[0023] Optionally, server 103 includes a second memory and a second processor. The second memory stores a recording data recovery program; the recording data recovery program is called by the second processor to implement the recording data recovery method provided in this application. Optionally, the second memory may include, but is not limited to, the following: RAM, ROM, PROM, EPROM, EEPROM. Optionally, the second processor may be a general-purpose processor, such as a CPU or NP.

[0024] In one optional embodiment, as shown in Table 1, the terminal device 101 includes an exit type determination module, a temporary cache management module, and a data recovery prompt module.

[0025]

[0026] The exit type determination module is used to directly monitor the lifecycle status (such as "active", "paused", "destroyed") of the audio mixing interface (or "recording studio page"), determine the application exit type (normal exit / abnormal exit), and send "clear cache" or "retain cache" instructions to the "temporary cache management module".

[0027] The temporary cache management module is used to perform cache operations (write / update / clear cache) according to the instructions of the exit type judgment module, and provide the cache data validity detection results to the "data recovery prompt module".

[0028] The data recovery prompt module is used to detect the validity of cached data when the application's home page is launched, trigger a prompt pop-up, and control the "temporary cache management module" to perform data reading or clearing operations according to the user's operation instructions.

[0029] In one optional embodiment, the terminal device 101 supports an Android or iOS system and has at least 100MB of available local storage space, a microphone, and a speaker. The local storage space is used to temporarily cache recording and tuning parameters, the microphone is used to record audio, and the speaker is used to play back the audio to preview the tuning effect. Optionally, the local storage space can be ROM storage space or other non-volatile storage space to ensure that cached data is not lost after the terminal device 101 restarts. The operating system version of the terminal device 101 needs to support the application's page lifecycle listening interface (e.g., Android's Activity lifecycle) to ensure that the exit type determination module can directly obtain the page lifecycle state of the tuning interface.

[0030] Figure 2 This is a flowchart illustrating a method for recovering audio recording data provided in an exemplary embodiment of this application. This method can be used as... Figure 1 The terminal device shown. The method includes the following steps.

[0031] Step 210: Display the application's tuning interface; the tuning interface displays the first recording and the first set of tuning parameters; the first set of tuning parameters is displayed based on the tuning operation of the first recording.

[0032] For example, the method is executed by an application running on the terminal, or by a client of an application running on the terminal. Optionally, the application is an application that supports recording functionality, such as a karaoke application.

[0033] Taking a karaoke application as an example, the terminal device can receive the user's action of opening the karaoke application and display the application's homepage. The user can select the song they want to sing on the homepage and enter the recording page for that song, where they can sing. After recording, the user enters the audio adjustment interface, which is used to adjust the audio parameters of the recorded audio, such as adding sound effects, modifying the style, re-recording segments, etc. The method provided in this application embodiment can be used to cache the audio adjustment process in real time within the adjustment interface, so that it can be restored if the application exits abnormally.

[0034] Alternatively, users can access the recording studio interface of the karaoke application, where they can record any audio. The difference between the recording studio interface and the song recording page is that the song recording page provides prompts such as accompaniment and lyrics to guide the user in recording a specific song, while the recording studio interface does not provide any song information, leaving the recording entirely to the user's discretion. In the recording studio interface, if a "stop recording" command is received, the user will also enter the tuning interface, where they can adjust the recorded audio. The tuning interface can also utilize the method provided in this application embodiment to cache the tuning process in real time, so that it can be restored if the application exits abnormally.

[0035] Of course, other applications can also provide a tuning interface, or an interface with similar functions, and the methods provided in the embodiments of this application can be applied in these interfaces. For example, an audio editing application can provide an audio editing interface where users can upload and edit audio, and the methods provided in the embodiments of this application can also be applied to the audio editing interface.

[0036] The audio tuning interface is used to enhance and correct the recording after it has been completed. It can optimize the balance between vocals and accompaniment and improve sound quality.

[0037] The audio tuning interface allows adjustment of various audio parameters, including at least one of the following: sound effect mode, accompaniment volume, vocal volume, vocal alignment, equalizer, intelligent pitch correction, noise reduction, voice changing, and pitch adjustment. Sound effect modes include various reverb effects such as studio, karaoke, magnetic, and distant, each creating a different sense of space and sound texture. Volume adjustment allows separate adjustment of the vocal and accompaniment volumes. Vocal alignment addresses the issue of vocals and accompaniment being out of sync. The equalizer (treble and bass adjustment) balances high and low frequencies, making the sound clearer or fuller, and supports custom or preset modes such as pop and blues. Intelligent pitch correction adjusts parameters such as pitch intensity and pitch sensitivity to correct out-of-tune notes while preserving natural vibrato. Noise reduction, voice changing (electronic, harmony, etc.), and pitch adjustment settings allow recordings to adapt to different vocal conditions.

[0038] The tuning interface can display at least one of the following: the name of the current song, the recording playback progress bar, the singing score (such as S, A, B, C levels), adjustment controls for vocal and accompaniment volume, sound effect mode selection controls, and a visual frequency band diagram of the equalizer; allowing users to adjust while listening and preview the effect in real time.

[0039] For example, the audio adjustment interface displays: a playback progress bar for the first recording, the song title of the first song corresponding to the first recording, a lyrics display area that scrolls with the playback progress, and a first set of adjustment parameters displayed after adjusting at least one of the above audio parameters. The first set of adjustment parameters can display the specific parameter values ​​after adjustment (e.g., selecting the recording studio sound effect mode, adjusting the reverb to 50, and the volume to 80); the first set of adjustment parameters can also display the control display status, such as the volume adjustment control slider being displayed at 30%, or the display positions of the various sliders on the equalizer.

[0040] For example, in the sound adjustment interface of a karaoke app, the user performs a series of sound adjustment operations on the first recording: First, the user selects the recording studio mode in the sound effect mode control; then, the accompaniment volume is adjusted from the default 80% to 60%; next, the vocal volume is increased from the default 70% to 85%; finally, in the equalizer, the gain of the low-frequency band (such as 100Hz) is increased from 0dB to +3dB, and the gain of the high-frequency band (such as 10kHz) is increased from 0dB to +2dB. After the above operations, the current first set of sound adjustment parameters is updated and displayed in real time according to each user interaction. The first set of sound adjustment parameters may include: sound effect mode is "recording studio", vocal volume is 85, accompaniment volume is 60, and the equalizer has a gain of +3dB for 100Hz and +2dB for 10kHz.

[0041] Step 220: With the tuning interface displayed, cache the first recording and the first set of tuning parameters to the buffer area.

[0042] For example, the first recording and the first set of tuning parameters are cached in the application's local persistent storage directory. A tuning interface cache folder is created in the local persistent storage directory, which is the cache area. The cache area can be located in the non-volatile storage area of ​​the terminal device to ensure that the data in the cache area will not be lost after the terminal device restarts.

[0043] For example, the first recording and initial tuning parameters can be cached in the buffer when entering the tuning interface. Subsequently, the first recording and the first set of tuning parameters can be cached periodically, or the first recording and the first set of tuning parameters can be cached after each operation received on the tuning interface, or the first recording and the first set of tuning parameters can be cached when the tuning interface enters the background or loses focus. It should be noted that the caching process is automatically executed by the terminal device or application and does not require manual operation by the user.

[0044] In one optional embodiment, while the user is logged in, the temporary cached data is synchronized to the APP's cloud server (such as the user's personal cloud space). When the user changes terminal devices or uninstalls and reinstalls the application, the recording data can be restored through cloud synchronization, further improving data security (cloud data is stored in encrypted form to protect user privacy). After the exit type judgment module determines that there is an abnormal exit, in addition to retaining the local cache, the cloud cache will also be retained.

[0045] That is, the application is logged in with a first user account. When the tuning interface is displayed, the cached first recording and the first set of tuning parameters are encrypted and uploaded to the server. The server is used to synchronize the cloud-cached first recording and the first set of tuning parameters to the application if the application logged in with the first user account does not detect the locally cached first recording and the first set of tuning parameters.

[0046] For example, the method in this embodiment is executed by a first client of the application, which uploads a first recording and a first set of tuning parameters to the server. If the terminal device uninstalls and reinstalls the first client, after logging into the first user account, the first client can retrieve the cached first recording and the first set of tuning parameters from the server and cache them locally. Alternatively, if the first user account logs into a second client of the application on another terminal device, the second client can retrieve the cached first recording and the first set of tuning parameters from the server and cache them locally.

[0047] Step 230: In response to the application's abnormal exit and restart, restore the tuning interface; the tuning interface displays the first recording and the first set of tuning parameters; the first set of tuning parameters is the same as the tuning parameters displayed on the tuning interface before the abnormal exit.

[0048] For example, abnormal exit refers to application exit behavior that does not trigger the page lifecycle destruction process. Abnormal exits can include: the user manually closing the application's background process (i.e., killing the background process), the application suddenly crashing due to a program error, or the operating system forcibly terminating the application process due to insufficient resources. In the case of abnormal exit, the application layer cannot perform the normal resource release and data cleanup process.

[0049] For example, after a user adjusts the first recording in the tuning interface, the application crashes suddenly due to a program error before the user clicks the save button. After the user restarts the application, the application automatically detects the cached first recording and first set of tuning parameters in the local cache, and then directly restores the tuning interface before the abnormal exit. The first recording and first set of tuning parameters displayed in the tuning interface are exactly the same as before the abnormal exit.

[0050] Optionally, the following can be adopted: Figure 3The method shown determines whether an application has exited abnormally. This method includes the following steps: Step 310: How to destroy the monitoring and tuning interface page.

[0051] Optionally, the page destruction method may include the onDestroy() method in the Android system or the dealloc() method in the iOS system.

[0052] For example, when running an Android system on a terminal device, the Activity class corresponding to the tuning interface is associated with a listener for the onDestroy() method (a key method in the lifecycle destruction process). When the onDestroy() method is called, it is determined that the page destruction process has been triggered (normal exit); if the onDestroy() method is not called when the APP (Application) exits (such as when the user closes the background), it is determined that the exit is abnormal.

[0053] For example, when running an iOS system on a terminal device, the UIViewController class corresponding to the tuning interface is associated with a listener for the dealloc() method. When the dealloc() method is executed, it is determined that the destruction process has been triggered (normal exit); if the dealloc() method is not executed when the APP exits, it is determined that the exit is abnormal.

[0054] After the exit type determination module generates the determination result, it immediately sends instructions to the temporary cache management module through in-process communication (such as Android's Handler or iOS's NotificationCenter) to ensure that cache operations and exit behavior are synchronized.

[0055] Step 320: If the application exits and the page destruction method is not called, determine that the application exited abnormally.

[0056] Optionally, if the application exits and the onDestroy() or dealloc() method is not called, determine if the application exited abnormally.

[0057] For example, the application will continuously listen for the page destruction method corresponding to the tuning interface; when the application exits, if it detects that the page destruction method has not been called, it indicates that the application did not end through the normal lifecycle destruction process, and thus the exit is determined to be an abnormal exit.

[0058] Step 330: If the application exits and the page destruction method is called, determine that the application exited normally.

[0059] Optionally, determine if the application exits normally if the onDestroy() or dealloc() method is called.

[0060] For example, the application will continuously listen for the page destruction method corresponding to the tuning interface; when the application exits, if it detects that the page destruction method has been called normally, it indicates that the application has followed the standard lifecycle destruction process (such as when the user actively clicks the back button to exit the application, or when the application is closed normally through the system task manager, etc.), and thus it is determined that this exit is a normal exit.

[0061] In one alternative embodiment, after the application restarts, the tuning interface may not be restored immediately. Instead, a restoration prompt pop-up may be displayed, asking the user whether they want to restore the tuning interface.

[0062] In response to an abnormal application exit and subsequent restart, a recovery prompt pop-up is displayed. This pop-up asks whether to restore the tuning interface displayed before the abnormal exit. If a confirmation to restore is received via the recovery prompt pop-up, the tuning interface is restored. If a cancellation to restore is received via the recovery prompt pop-up, the application displays the home page normally and deletes the first recording and first tuning parameters cached in the cache.

[0063] For example, after the `onCreate()` method of the application's homepage (Android) completes execution, it immediately requests the cache validity check result from the temporary cache management module. If the check passes, a pop-up window is triggered. The restore prompt pop-up has a medium priority; it does not interrupt the app's startup process, but the user must click "Restore" or "Cancel" before other operations can be performed (to prevent users from ignoring the restore prompt). After the user's action, the result is fed back to the temporary cache management module, which then performs the corresponding cache operation.

[0064] In one alternative embodiment, the cached data can also be scored, and the tuning interface can be automatically restored when the value of the cached data is high; when the value of the cached data is low, the user can be prompted whether to restore the tuning interface.

[0065] When the tuning interface is displayed, record editing behavior metrics; these metrics include at least one of the number of tuning operations and the editing duration of the tuning interface; determine the value score of cached data in the buffer based on the editing behavior metrics. If the value score is higher than a preset threshold, automatically restore the tuning interface; if the value score is not higher than the preset threshold, display a restore prompt pop-up; the restore prompt pop-up asks whether to restore the tuning interface displayed before the abnormal exit; in response to receiving confirmation of the restore operation through the restore prompt pop-up, restore the tuning interface.

[0066] The value score is a numerical value calculated based on user editing behavior metrics in the audio tuning interface (such as the number of tuning operations and editing time). It is used to quantify the level of editing effort or the importance of the cached data in the current cache. Based on the value score, differentiated data recovery strategies can be implemented: for high-value data (i.e., content that the user has invested a lot of effort in editing), it is automatically recovered directly, avoiding pop-up notifications to disturb the user; for low-value data (i.e., content that the user has only made a small amount of or quick editing), a pop-up is displayed to ask the user, giving the final decision-making power to the user, thus achieving the best balance between data protection and user experience.

[0067] The calculation method for value scores can be set according to business needs and / or user needs. For example, a weighted summation method can be used, assigning weights to the number of operations and editing time (e.g., 0.6 for the number of operations and 0.4 for editing time), and then calculating the weighted sum of the number of operations and editing time as the score. Alternatively, a threshold integration method can be used to calculate the value score, adding 10 points for each preset value of the number of operations (e.g., every 10 operations) and 5 points for each preset value of the editing time (e.g., every 1 minute), accumulating to obtain the total score. Another option is a segmented scoring method, dividing the number of operations and editing time into multiple intervals (e.g., 10 points for 0-1 minute editing time, 50 points for 1-5 minutes, and 100 points for more than 5 minutes), and then taking the average of the various scores as the final value score.

[0068] For example, a user extensively edits the first recording in the tuning interface, performing 15 tuning operations over a total editing time of 8 minutes. Based on the editing behavior index, a weighted summation method is used to calculate the value score of this cached data as 92 points (assuming a maximum score of 100). Because this score is higher than the preset threshold of 80 points, the data is deemed high-value. When the application crashes and restarts, the tuning interface is automatically restored, displaying the first recording and the first set of tuning parameters exactly as before the crash. The user can continue editing without any confirmation. Conversely, if the user only enters the tuning interface and performs one operation, with an editing time of only 5 seconds, the calculated value score is 10 points, lower than the preset threshold of 80 points. When the application restarts, a restore prompt pop-up will appear, asking the user, "Do you want to restore the incomplete tuning data?" Only after the user clicks "Restore" will the application restore the tuning interface as it was before the crash.

[0069] For example, if the application exits normally, the first recording and the first set of tuning parameters in the cache are cleared.

[0070] When the monitoring results from the exit type determination module confirm that the tuning interface has triggered its lifecycle destruction process (i.e., the onDestroy() or dealloc() methods are called normally), and the exit is deemed normal, the application will automatically perform a cleanup operation, deleting all the first recording and the first set of tuning parameters previously written to the buffer. In the case of a normal exit, when the user actively closes the application or tuning interface, it means the user has completed or abandoned the current editing work. The data in the buffer is no longer recoverable. Timely cleanup can prevent invalid temporary data from occupying the terminal device's storage space for a long time, achieving dynamic reclamation and effective management of the buffer space.

[0071] In an optional embodiment, the application may also record the received tuning operations as an operation log when the tuning interface is displayed; the operation log includes at least one operation record, each operation record corresponding to one tuning operation; and the operation log is stored in a third file in the cache.

[0072] For example, a user performs three audio adjustment operations on the first recording in the audio adjustment interface: first, adjusting the vocal volume from 70 to 80; second, switching the reverb mode from "Vocal Recording" to "Recording Studio"; and third, adjusting the equalizer's low-frequency gain from 0dB to +3dB. The application records these three adjustment operations sequentially as an operation log, with each operation log corresponding to one adjustment operation. For example, the first log is "Timestamp T1, Audio Adjustment Operation: Set vocal volume to 80", the second log is "Timestamp T2, Audio Adjustment Operation: Switch reverb mode to Recording Studio", and the third log is "Timestamp T3, Audio Adjustment Operation: Set equalizer low-frequency gain to +3dB". The operation log is stored in a third file in the cache to provide multiple version selection capabilities when recovering from an abnormal exit.

[0073] In response to an abnormal application exit and restart, read the operation log from the cache; display the version selection interface; the version selection interface shows at least one intermediate editing state, each intermediate editing state corresponding to an operation record in the operation log; in response to the selection operation of the target intermediate editing state, restore the tuning interface according to all operation records in the operation log before the target intermediate editing state.

[0074] Intermediate editing states are intermediate editing states that occur between the initial state and the final state during the user's tuning process, triggered by tuning operations. Each intermediate editing state corresponds to an operation record in the operation log, representing all parameter configurations on the tuning interface after the user performed that operation. Therefore, if we consider the user's entire tuning process as a timeline, the initial state is the first node, each operation creates a new node, which is the intermediate editing state, and the final state is the last node. For example, if the user adjusts the vocal volume, reverb mode, and equalizer sequentially, then each of the three nodes after adjusting the vocal volume, reverb mode, and equalizer corresponds to an intermediate editing state.

[0075] For example, the user's three audio tuning operations (setting the vocal volume to 80, switching the reverb mode to recording studio, and setting the equalizer's low-frequency gain to +3dB) are recorded as operation logs and stored in a third file. When the application restarts after an abnormal exit, the operation logs are read from the cache, and a version selection interface is generated. The version selection interface displays three intermediate editing states: the first intermediate editing state corresponds to "vocal volume 80" (at this time, the reverb is in the initial mode, and the equalizer is at its initial value); the second intermediate editing state corresponds to "vocal volume 80 + reverb to recording studio" (at this time, the equalizer is at its initial value); and the third intermediate editing state corresponds to "vocal volume 80 + reverb to recording studio + equalizer low-frequency gain +3dB" (i.e., the final state). If the user clicks the second intermediate editing state in the selection interface, the tuning interface will be restored according to all the operation records before this state in the operation log (i.e., the first two operations: setting the vocal volume to 80 and switching the reverb mode to recording studio). At this time, the tuning interface displays the vocal volume as 80 and the reverb mode as recording studio, but the equalizer is still at the initial value (i.e., the original state before the third adjustment).

[0076] In summary, the method provided in this embodiment caches the recording and tuning parameters on the tuning page when the application displays the tuning interface. If the application exits abnormally, the tuning interface is restored based on the cached recording and tuning parameters upon the next launch of the application, ensuring that the restored tuning interface is identical to the one displayed before the abnormal exit. This allows users to directly return to the previous editing state after the application is abnormally closed and restarted, avoiding the loss of tuning data due to unexpected interruptions. Furthermore, this method requires no manual user operation; the application can automatically complete data caching and interface restoration, reducing the user's operational costs.

[0077] The method provided in this embodiment automatically clears the recording and tuning parameters in the temporary cache when the user actively and normally closes the tuning interface or application. This avoids the situation where residual temporary data remains in the local cache after the user confirms that they have manually saved or abandoned the work, thus preventing it from occupying storage resources for a long time. This achieves dynamic reclamation of cache space and optimizes storage management.

[0078] The method provided in this embodiment, in the event of an abnormal exit, not only caching the data locally but also encrypting and uploading it to the server. When the user changes devices or uninstalls and reinstalls the software, they can retrieve the restored data from the cloud using the same account, solving the problem of local caching becoming invalid when the device is lost, and significantly improving data security and cross-device recovery capabilities.

[0079] The method provided in this embodiment accurately distinguishes the exit type by monitoring whether the page destruction method of the tuning interface (such as onDestroy() in Android and dealloc() in iOS) is called. The judgment logic is simple and the judgment result is accurate, which can effectively distinguish between scenarios where the user actively closes the process and scenarios where the process is forcibly terminated by the system or the user, providing a reliable decision basis for subsequent cache clearing or retention instructions.

[0080] The method provided in this embodiment does not directly restore the tuning interface when the application restarts after an abnormal exit. Instead, it first pops up a window asking the user whether to restore it, giving the final decision to the user. This avoids directly loading the previous tuning interface in inappropriate scenarios (such as when the user opens the app only to quickly view other content), respecting the user's intention and improving the user experience.

[0081] The method provided in this embodiment calculates the value score of the currently cached data by comprehensively considering the number of user operations and editing time in the audio tuning interface. For high-value data (such as data on which the user has invested a lot of effort in tuning), automatic recovery is triggered to reduce unnecessary interactions; for low-value data (such as data on which the user has just entered the page), a recovery pop-up is displayed to solicit user feedback. This achieves a balance between data protection and user disruption, improving the user experience.

[0082] The method provided in this embodiment logs each tuning operation and offers a version selection interface after an abnormal exit. This allows users to choose to revert to any satisfactory intermediate editing state during recovery (e.g., the version after the 5th reverb reduction operation), instead of being limited to the last state. This optimizes the user's editing experience and enhances the flexibility and creative freedom of data recovery.

[0083] For example, the recording is cached using incremental writing, while the tuning parameters are cached using overwrite writing.

[0084] Figure 4This is a flowchart illustrating a method for recovering audio recording data provided in an exemplary embodiment of this application. This method can be used as... Figure 1 The terminal device shown. Based on Figure 2 In the illustrated embodiment, step 220 includes steps 221 and 222; and / or, step 230 includes steps 231 and 232.

[0085] Step 210: Display the application's tuning interface; the tuning interface displays the first recording and the first set of tuning parameters; the first set of tuning parameters is displayed based on the tuning operation of the first recording.

[0086] Step 221: With the tuning interface displayed, create a tuning interface cache folder in the application's local persistent storage directory; the tuning interface cache folder includes a first file and a second file.

[0087] For example, create a folder named "TempRecordingCache" (i.e., the tuning interface cache folder) in the app's private storage directory, which contains two files: The first file, "auto_save_record.pcm", stores the raw recording data (pcm format, supports breakpoint writing).

[0088] The second file, “tuning_params.json”, stores tuning parameters (in JSON format, containing fields such as parameter name and parameter value, e.g., {"reverb_type":"hall","volume":80}).

[0089] Step 222: Write the first recording to the first file in an incremental append mode, and write the first set of tuning parameters to the second file in an overwrite mode; the incremental append mode is used to append the newly written audio data to the end of the existing data in the first file; the overwrite mode is used to replace the tuning parameters already stored in the second file with the newly written tuning parameters.

[0090] The audio mixing interface also allows you to re-record parts of the first recording or to supplement the first recording.

[0091] For example, a user might find that the first recording in the tuning interface is missing a line of a cappella singing in the intro (or a line of harmony at the end). The user can click "Record Supplement" to record a new audio segment while keeping the existing recording. After recording, the newly recorded audio is incrementally appended to the corresponding position (beginning or end) of the first recording, creating an updated first recording. On the tuning interface, the duration of the first recording will increase accordingly, and the newly added supplementary segment will be displayed on the progress bar.

[0092] For example, a user might find that the end of the first recording is missing a high-pitched harmony note and want to add an extra harmony track without affecting the already recorded vocals. The user can click the "Add Record" function to record a new audio clip as an overlay while maintaining the existing recording (similar to overlay recording in multitrack recording). After recording, the newly recorded audio is incrementally appended to the first recording, keeping the original recording unchanged. The tuning interface will then display the updated first recording (original recording + added audio), allowing the user to further adjust the volume and position of the added portion. Based on the caching mechanism, the updated first recording, including the added content, is written to the first file in the cache area.

[0093] Optionally, for re-recorded segments, an overwrite method can be used for caching. When a user plays the first recording in the tuning interface, they might notice a significant pitch distortion or off-key note in the chorus, while the verses are fine. The user can use the re-recording function provided in the tuning interface to select the segment to be re-recorded (e.g., from 1 minute 20 seconds to 1 minute 35 seconds) on the recording playback progress bar, and then record the selected segment separately. After recording, the newly recorded audio segment replaces the corresponding audio data in the original recording, creating an updated first recording. The tuning interface remains unchanged, but the waveform of the first recording in that segment area will be updated.

[0094] In the audio mixing interface, users can adjust the audio parameters of the first recording. For example, when a user adjusts the first recording in the mixing interface, the application writes a set of default mixing parameters to a second file, overwriting the existing parameters. The file's content is: {"reverb_type":"Vocal Recording","volume":70,"accompaniment_volume":80}. Subsequently, the user adjusts the vocal volume from 70 to 85. Upon detecting this adjustment, the application immediately writes the updated first set of mixing parameters to the second file, completely replacing the existing content with: {"reverb_type":"Vocal Recording","volume":85,"accompaniment_volume":80}. Then, the user switches the reverb mode from "Vocal Recording" to "Studio Recording," triggering another overwrite. The second file's content is updated to: {"reverb_type":"Studio Recording","volume":85,"accompaniment_volume":80}. As can be seen, after each write, the tuning parameters in the second file are the user's latest tuning configuration, and the previously stored old parameters are completely replaced, ensuring that the file always saves the latest set of valid parameters.

[0095] For example, the application can update cached data in response to a tuning operation; it can also update cached data in response to a change in the lifecycle state of the tuning interface; or it can update cached data periodically.

[0096] In one optional embodiment, in response to receiving a tuning operation, after a preset time has elapsed since the tuning operation was received, the first set of tuning parameters is written to a second file; if a tuning operation is received again within the preset time, the timer is reset.

[0097] For example, the preset duration is 5 seconds. The user quickly and continuously drags the vocal volume slider, adjusting the volume sequentially from 70 to 75 (second 0), from 75 to 80 (second 2), and from 80 to 85 (second 4). Since each new adjustment operation occurs within the preset 5 seconds, the timer resets each time a new operation is detected. Therefore, no write operations are performed during the continuous operation. Only after the user completes the last adjustment at second 4, and no further adjustments are made, does the timer start. When the countdown reaches 5 seconds (i.e., at second 9), the latest first set of adjustment parameters (vocal volume of 85) is written to the second file in an overwrite manner.

[0098] In one alternative embodiment, in response to detecting a change in the lifecycle state of the tuning interface, the first recording and the first set of tuning parameters currently displayed on the tuning interface are written to the buffer; the lifecycle state change includes the tuning interface entering the background state or losing focus.

[0099] Losing focus refers to the state where the audio tuning interface changes from being the active foreground element of user interaction to no longer being the interface the user is directly interacting with. This can occur when the user taps an area of ​​the screen outside the audio tuning interface (such as the notification bar, system dialog boxes, or floating windows of other applications), or partially or completely obscures the audio tuning interface through gestures (such as swiping to switch tasks). In this situation, although the audio tuning interface may still be visible (not completely in the background), it is no longer the primary target for receiving user touch events.

[0100] For example, a user is adjusting the parameters of the first recording in the tuning interface of a karaoke app, setting the vocal volume to 80 and switching the reverb mode to "Recording Studio." Suddenly, a WeChat message notification pops up at the top of the screen. The user clicks on the notification, causing the tuning interface to immediately lose focus. Although the tuning interface remains semi-transparently displayed on the screen, it is no longer the primary interface for user interaction. Upon detecting this lifecycle state change, the application immediately writes the currently displayed first recording and the latest set of tuning parameters to the cache to ensure that the current editing state of the tuning interface is not lost due to any subsequent abnormal exit while the user is viewing the WeChat message.

[0101] For example, the cache update frequency can be designed to be once every 10 seconds or updated immediately after the user adjusts the tuning parameters. It is not limited to key data and can include all tuning data, further extending the integrity and real-time performance of the data.

[0102] For example, an application can be designed to automatically trigger a cache write every 10 seconds, or trigger an instant update immediately after each user adjusts tuning parameters (such as reverb, volume, equalizer, etc.). The cached data is not limited to critical data, but can include all tuning data (such as sound effect modes, accompaniment volume, vocal volume, vocal alignment, equalizer gain for each frequency band, intelligent pitch correction intensity, noise reduction level, voice changing mode, pitch shifting, and all other parameters). By increasing the frequency and coverage of cache updates, every subtle operation performed by the user in the tuning interface can be saved more completely and in real time. This ensures that in the event of an abnormal exit, the latest state of all user tuning parameters can be restored to the greatest extent possible, further extending the integrity and real-time nature of the data.

[0103] Step 231: In response to the application exiting abnormally and restarting, perform integrity verification on the first and second files in the cache and obtain the verification results.

[0104] For example, each time the application homepage is launched, it checks whether the "TempRecordingCache" folder exists, whether the cache file has non-empty data, and whether the path of the automatically saved PCM file is recorded. If the conditions are met, it is determined that "there is valid data"; otherwise, it is determined that "there is no valid data" and the cache is cleared. At the same time, it receives instructions from the exit type judgment module and performs cache clearing or retention operations in real time.

[0105] Step 232: If the verification result indicates that both the first and second files are complete, restore the tuning interface based on the first and second files.

[0106] For example, if the tuning interface cache folder exists, and the first and second files are not empty data, and the application records the file path of the first file, it is determined that both the first and second files are complete.

[0107] Optionally, if the verification result indicates that a file is missing, display the application's homepage.

[0108] Optionally, if the verification result indicates that the first file is incomplete, the audio data in the first file is truncated to the nearest complete audio frame. The tuning interface is then restored based on the truncated first and second files; the duration of the first recording displayed in the restored tuning interface is shorter than the duration of the first recording before the abnormal exit.

[0109] For example, a user edits and adjusts the first recording for about 3 minutes in the tuning interface, at which point the application crashes. Upon restarting the application, before restoring, the application checks the integrity of the first file in the cache and finds that the end of the recording file is corrupted due to the crash, with the last audio segment incomplete. The application then discards the data after the corrupted end of the file and truncates the audio data to the nearest complete audio frame, assuming the truncated effective recording duration is 2 minutes and 50 seconds. Then, the application restores the tuning interface based on the truncated first file (containing 2 minutes and 50 seconds of effective recording data) and the complete second file (tuning parameter file). In the restored tuning interface, the first recording duration is 2 minutes and 50 seconds, shorter than the original 3-minute recording before the crash, but it includes the effective portion that the user has already tuned. The user can continue editing or adding to the recording based on this truncated portion.

[0110] Optionally, if the verification result indicates that the second file is incomplete, the stored tuning parameters are parsed from the second file, and the missing tuning parameters are supplemented with preset default values. The tuning interface is restored based on the first file and the supplemented second file; the first set of tuning parameters displayed in the restored tuning interface includes at least one default value parameter.

[0111] For example, a user edits a first recording in the audio mixing interface, adjusting three parameters: vocal volume, reverb mode, and equalizer low-frequency gain. If the application then crashes, the second file in the buffer becomes incomplete due to a write interruption. When the user restarts the application, it parses the second file and finds that only some parameters are successfully stored, such as {"reverb_type":"recording studio","volume":80}, but the "equalizer low-frequency gain" parameter (eq_low_gain) is missing. The system then fills in the missing "equalizer low-frequency gain" parameter with a default value (e.g., 0dB), generating a complete second file with the content {"reverb_type":"recording studio","volume":80,"eq_low_gain":0}. The system then restores the audio mixing interface based on the complete first file and the supplemented second file. In the restored audio interface, the original audio of the first recording is complete, the vocal volume is 80, the reverb mode is "Recording Studio" and retains the settings before the abnormal exit, while the low-frequency gain of the equalizer is displayed as the default 0dB (that is, the default value automatically filled by the system when the user did not successfully save the parameter before the abnormal exit). The user can continue to adjust or edit it based on this.

[0112] For example, the restored tuning interface displays restoration status information; the restoration status information is used to indicate the integrity of the first recording and the first set of tuning parameters after restoration relative to the state before the abnormal exit.

[0113] For example, a user edits and adjusts approximately 3 minutes of the first recording in the audio mixing interface, setting the vocal volume to 80, switching the reverb mode to "Recording Studio," and adjusting the equalizer's low-frequency gain to +3dB. At this point, the application crashes. The next time the user launches the application, during an integrity check of the first file in the cache, it's discovered that the end of the file is corrupted due to the crash. Therefore, the audio data is truncated to the most recent complete audio frame, resulting in a valid recording duration of 2 minutes and 50 seconds. Simultaneously, parsing the second file reveals that it only fully preserves "Voice Volume: 80" and "Reverb Mode: Recording Studio," but lacks the "Equalizer Low-Frequency Gain" parameter. Therefore, the system replenishes this missing parameter with the default value of 0dB. After restoring the audio mixing interface based on the truncated first file and the replenished second file, the system displays a recovery status message, such as: "Recording data restored (2 minutes 50 seconds / original 3 minutes), audio mixing parameters: vocal volume 80 (restored), reverb mode: recording studio (restored), equalizer low-frequency gain: 0dB (default value)." The status message clearly indicates to the user that the first recording after recovery is 10 seconds shorter than the original recording before the abnormal exit (due to the audio being truncated due to damage at the end). The vocal volume and reverb mode in the tuning parameters have been fully restored, but the low-frequency gain of the equalizer has been replaced by the default value by the system due to the incomplete file, prompting the user to readjust this parameter.

[0114] In summary, the method provided in this embodiment creates dedicated cache folders and cache files (first file and second file), and adopts differentiated writing strategies for different types of cached data. It uses an "incremental append" method for the original recording data (first file) and an "overwrite" method for the tuning parameters (second file). The incremental append method flexibly addresses potential re-recording scenarios during the tuning process, while the overwrite method ensures that the tuning parameters are always up-to-date and the file structure remains simple, thus achieving a balance between storage efficiency and data integrity.

[0115] The method provided in this embodiment avoids triggering a large number of meaningless write operations when users frequently and quickly adjust tuning parameters (such as continuously dragging the slider), by setting a preset duration. This reduces the consumption of buffer I / O (Input / Output) resources and prevents performance problems (such as interface lag) caused by excessively frequent writing. It optimizes system performance while ensuring data real-time performance.

[0116] The method provided in this embodiment ensures that when the audio tuning interface enters the background or loses focus due to answering a call, switching to another application, or other reasons, the system immediately performs a cache write. This provides additional data protection for users during uncontrollable, brief periods of absence, ensuring that the state of the operation is saved in a timely manner and guaranteeing data integrity.

[0117] The method provided in this embodiment first determines whether the recording data and tuning parameter files in the cache directory are complete and usable before restoring the tuning interface. The restoration operation is only performed if the verification passes, thereby avoiding restoration failure or the recovery of abnormal data due to cache file corruption, missing files, or other anomalies, thus improving the stability and reliability of the restoration process.

[0118] The method provided in this embodiment offers a low-overhead, high-precision judgment standard by verifying three conditions: whether the cache folder exists, whether the file is empty, and whether the file path is recorded. This standard can quickly exclude invalid or abnormal cached data, thereby ensuring that the recovery process is executed only when the data is available.

[0119] The method provided in this embodiment directly displays the homepage when the system determines that the cache file is missing (i.e., it cannot be restored), avoiding the application startup process being blocked by an invalid restoration operation. This ensures that users can enter the app normally regardless of the cache status, improving the robustness of the startup process and the smoothness of the user experience.

[0120] The method provided in this embodiment does not directly abandon the audio file (first file) when it is damaged or incomplete due to abnormal exit. Instead, it intelligently truncates the data to the most recent complete audio frame and restores the audio mixing interface based on this valid data. This partial restoration strategy preserves the user's completed editing work to the greatest extent possible, minimizing loss.

[0121] The method provided in this embodiment allows the application to parse existing valid parameters and automatically fill in the missing parameters with preset default values ​​when the tuning parameter file (second file) is incomplete. This ensures that the restored tuning interface has a normal working configuration, and the user only needs to make minor adjustments after restoration. This avoids the entire tuning interface failing to load due to the corruption of a single tuning parameter, thus improving the flexibility of restoration.

[0122] The method provided in this embodiment displays a prompt message (such as "Recovering the missing second half of the recording" or "Using default values ​​for some tuning parameters") in a pop-up window or on the interface when the recovered data is not 100% complete. This allows users to intuitively understand the completeness of the data recovery, avoiding confusion or the mistaken belief that the data has been fully recovered, and improving the transparency of the interaction.

[0123] An example is provided of an embodiment of restoring the tuning interface using the recording data recovery method provided in this application in a karaoke application.

[0124] Figure 5 This is a flowchart illustrating the user's journey from entering the sound adjustment interface of a karaoke application to exiting the application. This method can be used for, for example... Figure 1 The terminal device shown. The method includes the following steps.

[0125] Step 401: The user enters the tuning interface.

[0126] Optionally, the user opens the karaoke application, clicks on the first song to enter the recording interface for that song, sings the first song in the recording interface, and obtains the first recording. After recording, the user is redirected to the tuning interface, where they can adjust the audio of the first recording to obtain the karaoke version.

[0127] Alternatively, this method can be applied to the "recording studio" function module of a karaoke app. Users open the karaoke app, click the recording studio function, enter the recording studio interface (i.e., the sound mixing interface), record audio in the recording studio interface, and then adjust the sound of the recording.

[0128] The audio adjustment interface is used in the audio adjustment stage "after recording is completed and before manual saving". For example, after a user finishes recording a song, they enter the audio adjustment interface to adjust parameters such as reverb, volume, and sound effects. If they do not click the "save" button and accidentally close the app in the background, the method provided in this application embodiment can be used to restore the audio adjustment interface. For example, if the app suddenly crashes due to a program error during the audio adjustment process, or if the operating system forcibly terminates the karaoke app process due to insufficient resources.

[0129] Step 402: Start the real-time caching mechanism: ① Initialize and save basic configuration data when entering the interface; ② Trigger incremental saving at any time during user operations (such as adjusting parameters / recording).

[0130] Optionally, a real-time caching mechanism can be activated after entering the tuning interface to immediately save the current basic configuration data upon entering the tuning interface; and, during subsequent user operations (such as adjusting parameters), the latest data changes can be written to the temporary cache at any time to achieve incremental saving.

[0131] Step 403: Exit Type Determination Module: Monitors the page lifecycle status. If "Lifecycle Destruction in Progress" (i.e., actively exiting / normally closing the application) is detected, proceed to Step 404. If "Lifecycle Destruction in Progress" is not detected (i.e., crashing / forcefully closing the application), proceed to Step 405.

[0132] The exit type determination module starts listening to the page lifecycle state of the tuning interface to determine whether the exit of the karaoke application is a normal exit triggered by the user or an abnormal exit caused by a crash, background killing, etc.

[0133] Step 404: If the exit is determined to be normal, perform the cache clearing operation to clear the temporary local cache.

[0134] If it is determined that the application is performing a standard shutdown process, at which point the tuning work has been completed or the user has consciously exited, then the recording data stored in the temporary cache should be cleared to avoid occupying invalid storage space.

[0135] Step 405: The exit is determined to be abnormal. At this time, the cached data has been automatically saved along with the operation in the previous step 402.

[0136] If it is determined that the application exited against the user's will, and due to the real-time caching mechanism in step 402, the latest recording data and tuning parameters have been automatically saved to the temporary cache before exiting, no additional operation is required.

[0137] Step 406: The user exits the application, and the first exit process ends.

[0138] This concludes the user's first experience using the karaoke application. Data from any abnormal exits has been properly retained via temporary caching.

[0139] Figure 6 This is a flowchart illustrating the process of a user restarting the karaoke application and returning to the homepage after an abnormal exit. This method can be used for, for example... Figure 1 The terminal device shown. The method includes the following steps.

[0140] Step 501: The user launches the karaoke application again.

[0141] Optionally, the user can reopen the karaoke application after experiencing an application exit (e.g., an abnormal exit).

[0142] Step 502: Go to the homepage of the karaoke application.

[0143] The karaoke application has started up and you will be taken to its main interface (homepage).

[0144] Step 503: Data recovery prompt module: Check if there is valid data in the temporary cache. If there is no valid cache, proceed to step 504. If there is a valid cache, proceed to step 505.

[0145] Optionally, the system can automatically check the temporary cache folder (i.e., the tuning interface cache folder) created previously to handle abnormal exits to determine if it contains valid recording data and tuning parameters from the previous unfinished session.

[0146] Step 504: The homepage is displayed normally, and the startup process ends.

[0147] If there is no valid cache, the process will end directly and the homepage will be displayed normally.

[0148] Step 505: A recovery prompt window pops up ("Recover incomplete tuning data?"). If the user clicks the "Cancel" button, proceed to step 506. If the user clicks the "Recover" button, proceed to step 507.

[0149] If a valid cache exists, a restore prompt pop-up will appear on the interface, asking the user if they want to restore the previously unfinished tuning. The user can choose "Restore" or "Cancel".

[0150] Step 506: Initiate the cancellation process and clear the temporary local cache.

[0151] If the user chooses not to restore, all data in the temporary cache folder will be cleared according to the user's instructions to free up storage space.

[0152] Step 507: Temporary Cache Management Module: Reads cached data. The tuning interface loads the cached tuning data and parameters, restoring the editing interface. The user can continue editing (performing tuning or saving operations, etc.), and this startup process ends.

[0153] If the user chooses to restore, the temporary cache management module is invoked, and previously saved recording data and tuning parameters are read from the cache file. The read audio file and tuning parameters are loaded into the tuning interface, completely restoring the editing state before the user's abnormal exit. The user can then continue to adjust the audio parameters or save the work, thus concluding this data recovery and restart process.

[0154] In summary, the method provided in this embodiment addresses the issue of lost recording and tuning data in karaoke apps during the recording studio setting when users exit unexpectedly (e.g., the app is killed in the background or crashes). It proposes an automatic method for saving and restoring recording data. An exit type determination module directly monitors the lifecycle state of the recording studio function page to determine the exit type: if the lifecycle destruction process is triggered, the temporary local cache is automatically cleared to prevent invalid data from occupying storage; if the destruction process is not triggered (i.e., abnormal exit), the recording and tuning data in the temporary cache are retained. When the user launches the app again and enters the homepage, the system automatically detects the local cache data, prompts the user to restore the recording data, and after confirmation, the original recording file and tuning parameters are fully restored based on the cached data, resolving the data loss problem and improving the user experience. The page lifecycle state detection and dynamic local cache management are directly linked through the exit type determination module, achieving a "save on demand, restore accurately" recording data protection mechanism.

[0155] The method provided in this embodiment achieves automatic protection and differentiated processing of tuning interface data through the coordinated linkage of a real-time caching mechanism and an exit type judgment module. No manual saving is required from the user; the cache is automatically initialized when the user enters the tuning interface, and recording data and tuning parameters are incrementally saved in real time during user operation, preventing the loss of editing results. The exit type judgment module monitors the page lifecycle state to distinguish between normal and abnormal exit scenarios. When the user actively exits normally, the temporary cache is automatically cleared to prevent invalid data from occupying storage resources, achieving dynamic cache management. Conversely, when the user exits abnormally due to application crashes, accidental killing of background processes, or other reasons, the saved cached data is automatically retained. Thus, without increasing the user's operational burden, it provides data security in abnormal scenarios and prevents the long-term accumulation of invalid cache, improving storage resource utilization efficiency.

[0156] The method provided in this embodiment automatically detects and prompts the user to recover incomplete tuning data when the application restarts, offering an intelligent and low-interference data recovery experience. When the user launches the karaoke application and enters the homepage again, the data recovery prompt module automatically detects the validity of the temporary cache and proactively prompts the user with a pop-up window if a valid cache exists. This eliminates the need for the user to manually search for unsaved files, reducing the user's operation time cost. If the user selects "Recover," the system reads the original recording data and tuning parameters from the cache, completely restoring the tuning interface state before the abnormal exit, allowing the user to seamlessly continue editing and avoiding the high-cost operation of repeated recording and tuning. If the user selects "Cancel," the system automatically clears the invalid cache, preventing redundant data from occupying storage space for a long time. Furthermore, this method uses a medium-priority pop-up design, which does not interrupt the application startup process but ensures that the user must complete the recovery decision before proceeding with subsequent operations. This ensures both the timeliness of data recovery and the smoothness of interface interaction, significantly improving user trust and stickiness with the application.

[0157] The method provided in this embodiment constructs a complete data protection chain of "judgment-storage-recovery". The exit type judgment module directly undertakes the functions of page lifecycle monitoring and exit type determination, realizing dynamic management of recording and tuning data and effectively avoiding data loss in abnormal exit scenarios. A temporary cache space is opened locally, and cached data is retained in the event of abnormal exit, providing a data foundation for subsequent recovery. The exit type judgment module directly determines the exit type based on the page lifecycle destruction process. The cache is cleared in the event of normal exit and the cache is retained in the event of abnormal exit, realizing dynamic cache management and avoiding storage waste. The cache utilization rate reaches 100% (no invalid cache residue in the event of normal exit); the data recovery success rate is ≥99% (based on standard hardware environment and normal cache files).

[0158] The method provided in this embodiment does not require users to manually enable the auto-save function. The system automatically protects the data in the background, reducing user operation costs. After an abnormal exit, the data can be quickly restored when the APP is launched again, avoiding users from having to re-record and adjust the sound, thus increasing users' trust in the APP and their stickiness in using it.

[0159] The method provided in this embodiment accurately determines the exit type through the exit type judgment module, dynamically clears invalid cache, avoids temporary data from occupying the phone's storage for a long time, and reduces the APP's consumption of terminal device storage resources; at the same time, it simplifies the module architecture and reduces system resource consumption.

[0160] It should be noted that this application may display prompt interfaces, pop-ups, or output voice prompts before and during the collection of user data. These prompt interfaces, pop-ups, or voice prompts are used to inform the user that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt interface or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected in this application is collected with the user's consent and authorization, and the collection, use, and processing of related user data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0161] It should be noted that the order of the method steps provided in the embodiments of this application can be appropriately adjusted, and the steps can also be added or removed as appropriate. The steps in the above embodiments can also be arbitrarily combined to obtain new embodiments. Any variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application, and therefore will not be elaborated further.

[0162] Figure 7 This is a schematic diagram of a recording data recovery apparatus provided in an exemplary embodiment of this application. The apparatus includes: Display module 1001 is used to display the tuning interface of the application; the tuning interface displays a first recording and a first set of tuning parameters; the first set of tuning parameters is displayed according to the tuning operation of adjusting the first recording; Cache module 1002 is used to cache the first recording and the first set of tuning parameters to a cache area when the tuning interface is displayed; The recovery module 1003 is used to restore the tuning interface in response to the abnormal exit and restart of the application; the tuning interface displays the first recording and the first set of tuning parameters; the first set of tuning parameters is the same as the tuning parameters displayed on the tuning interface before the abnormal exit.

[0163] In an optional embodiment, the caching module 1002 is configured to create a tuning interface cache folder in the local persistent storage directory of the application; the tuning interface cache folder includes a first file and a second file; The caching module 1002 is used to write the first recording to the first file in an incremental append mode, and to write the first set of tuning parameters to the second file in an overwrite mode; the incremental append mode is used to append the newly written audio data to the end of the existing data in the first file; the overwrite mode is used to replace the tuning parameters already stored in the second file with the newly written tuning parameters.

[0164] In an optional embodiment, the caching module 1002 is configured to, in response to receiving a tuning operation, write the first set of tuning parameters into the second file after a preset time has elapsed since receiving the tuning operation; The buffer module 1002 is used to reset the timer if a tuning operation is received again within the preset time period.

[0165] In an optional embodiment, the caching module 1002 is configured to write the first recording and the first set of tuning parameters currently displayed on the tuning interface into the cache area in response to detecting a change in the lifecycle state of the tuning interface; the lifecycle state change includes the tuning interface entering a background state or losing focus.

[0166] In an optional embodiment, the recovery module 1003 is used to perform integrity verification on the first file and the second file in the cache area to obtain a verification result; The recovery module 1003 is used to recover the tuning interface based on the first file and the second file when the verification result indicates that both the first file and the second file are complete.

[0167] In an optional embodiment, the recovery module 1003 is used to determine that both the first file and the second file are complete when the tuning interface cache folder exists, the first file and the second file are non-empty data, and the application has recorded the file path of the first file.

[0168] In an optional embodiment, the display module 1001 is configured to display the homepage of the application in the event that the verification result indicates the file is missing.

[0169] In an optional embodiment, the recovery module 1003 is configured to truncate the audio data in the first file to the nearest complete audio frame when the verification result indicates that the first file is incomplete. The recovery module 1003 is used to recover the tuning interface based on the truncated first file and the second file; the duration of the first recording displayed on the recovered tuning interface is shorter than the duration of the first recording before the abnormal exit.

[0170] In an optional embodiment, the recovery module 1003 is used to parse the stored tuning parameters from the second file and supplement the missing tuning parameters with preset default values ​​when the verification result indicates that the second file is incomplete; The recovery module 1003 is used to recover the tuning interface based on the first file and the supplemented second file; the first set of tuning parameters displayed in the recovered tuning interface includes at least one default value parameter.

[0171] In one optional embodiment, the restored tuning interface displays restoration status information; the restoration status information is used to indicate the integrity of the restored first recording and the first set of tuning parameters relative to the state before the abnormal exit.

[0172] In an optional embodiment, the caching module 1002 is configured to clear the first recording and the first set of tuning parameters from the cache area when the application exits normally.

[0173] In one alternative embodiment, the application is logged in with a first user account; The caching module 1002 is used to encrypt and upload the cached first recording and the first set of tuning parameters to the server when the tuning interface is displayed. The server is configured to synchronize the first recording and the first set of tuning parameters cached in the cloud to the application when the application logged in with the first user account does not detect the first recording and the first set of tuning parameters cached locally.

[0174] In an optional embodiment, the recovery module 1003 is used to monitor the page destruction method of the tuning interface; The recovery module 1003 is used to determine that the application has exited abnormally when the application exits and the page destruction method is not called. The recovery module 1003 is used to determine that the application has exited normally when the application exits and the page destruction method is called.

[0175] In an optional embodiment, the recovery module 1003 is configured to display a recovery prompt pop-up in response to the application's abnormal exit and restart; the recovery prompt pop-up is used to ask whether to restore the tuning interface displayed before the abnormal exit; The recovery module 1003 is used to restore the tuning interface in response to receiving a confirmation of recovery operation through the recovery prompt pop-up window.

[0176] In an optional embodiment, the caching module 1002 is used to record editing behavior indicators when the tuning interface is displayed; the editing behavior indicators include at least one of the number of tuning operations and the editing duration of the tuning interface; The value score of the cached data in the cache area is determined based on the editing behavior indicators.

[0177] In an optional embodiment, the recovery module 1003 is used to automatically restore the tuning interface when the value score is higher than a preset threshold. If the value score is not higher than the preset threshold, a recovery prompt pop-up window is displayed; the recovery prompt pop-up window is used to ask whether to restore the tuning interface displayed before the abnormal exit; in response to receiving a confirmation of recovery operation through the recovery prompt pop-up window, the tuning interface is restored.

[0178] In an optional embodiment, the caching module 1002 is used to record the received tuning operation as an operation log when the tuning interface is displayed; the operation log includes at least one operation record, and each operation record corresponds to one tuning operation; The caching module 1002 is used to store the operation log in a third file in the cache area.

[0179] In an optional embodiment, the recovery module 1003 is configured to read the operation log from the cache in response to the application's abnormal exit and restart. The recovery module 1003 is used to display a version selection interface; the version selection interface displays at least one intermediate editing state, and each intermediate editing state corresponds to an operation record in the operation log; The recovery module 1003 is used to respond to the selection operation of the target intermediate editing state and restore the tuning interface according to all operation records in the operation log before the target intermediate editing state.

[0180] It should be noted that the audio recording data recovery device provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the audio recording data recovery device and the audio recording data recovery method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0181] Embodiments of this application also provide a computer device, comprising: a processor and a memory, wherein the memory stores at least one instruction, at least one program, code set, or instruction set, and the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the recording data recovery method provided in the above-described method embodiments. This computer device can be implemented as a terminal device.

[0182] For example, Figure 8 This is a schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application.

[0183] Typically, computer device 1700 includes a processor 1701 and a memory 1702.

[0184] Processor 1701 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1701 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1701 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1701 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1701 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0185] The memory 1702 may include one or more computer-readable storage media, which may be non-transitory. The memory 1702 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1702 is used to store at least one instruction, which is executed by the processor 1701 to implement the method for recovering recording data provided in the method embodiments of this application.

[0186] In some embodiments, the computer device 1700 may also optionally include a peripheral device interface 1703 and at least one peripheral device. The processor 1701, memory 1702, and peripheral device interface 1703 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1703 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 1704, a display screen 1705, a camera assembly 1706, an audio circuit 1707, and a power supply 1708.

[0187] Peripheral device interface 1703 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 1701 and memory 1702. In some embodiments, processor 1701, memory 1702 and peripheral device interface 1703 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1701, memory 1702 and peripheral device interface 1703 can be implemented on separate chips or circuit boards, which is not limited in this application embodiment.

[0188] The radio frequency (RF) circuit 1704 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1704 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1704 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 1704 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 1704 can communicate with other computer devices via at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 1704 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0189] Display screen 1705 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 1705 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 1701 for processing. In this case, display screen 1705 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 1705, which is located on the front panel of computer device 1700; in other embodiments, there may be at least two display screens 1705, respectively located on different surfaces of computer device 1700 or in a folded design; in still other embodiments, display screen 1705 may be a flexible display screen, located on a curved or folded surface of computer device 1700. Furthermore, display screen 1705 may also be configured as a non-rectangular, irregular shape, i.e., a non-rectangular screen. The display screen 1705 can be made of materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0190] The camera assembly 1706 is used to acquire images or videos. Optionally, the camera assembly 1706 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the computer device 1700, and the rear-facing camera is located on the back of the computer device. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 1706 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm light flash and a cool light flash, which can be used for light compensation at different color temperatures.

[0191] The audio circuit 1707 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting them into electrical signals that are input to the processor 1701 for processing, or to the radio frequency circuit 1704 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, positioned at different locations within the computer device 1700. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert electrical signals from the processor 1701 or the radio frequency circuit 1704 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 1707 may also include a headphone jack.

[0192] Power supply 1708 is used to supply power to the various components in computer device 1700. Power supply 1708 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery. When power supply 1708 includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery that is charged via a wired line, and a wireless rechargeable battery is a battery that is charged via a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0193] In some embodiments, the computer device 1700 further includes one or more sensors 1709. The one or more sensors 1709 include, but are not limited to, an accelerometer 1710, a gyroscope 1711, a pressure sensor 1712, an optical sensor 1713, and a proximity sensor 1714.

[0194] Accelerometer 1710 can detect the magnitude of acceleration along the three coordinate axes of a coordinate system established by computer device 1700. For example, accelerometer 1710 can be used to detect the components of gravitational acceleration along the three coordinate axes. Processor 1701 can control touchscreen display 1705 to display the user interface in landscape or portrait view based on the gravitational acceleration signal acquired by accelerometer 1710. Accelerometer 1710 can also be used for games or for acquiring user motion data.

[0195] The gyroscope sensor 1711 can detect the orientation and rotation angle of the computer device 1700. The gyroscope sensor 1711 can work in conjunction with the accelerometer sensor 1710 to acquire 3D motion data from the user on the computer device 1700. Based on the data acquired by the gyroscope sensor 1711, the processor 1701 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.

[0196] Pressure sensor 1712 can be disposed on the side bezel of computer device 1700 and / or on the lower layer of touch display screen 1705. When pressure sensor 1712 is disposed on the side bezel of computer device 1700, it can detect the user's grip signal on computer device 1700, and processor 1701 can perform left / right hand recognition or quick operation based on the grip signal collected by pressure sensor 1712. When pressure sensor 1712 is disposed on the lower layer of touch display screen 1705, processor 1701 can control operable controls on the UI interface based on the user's pressure operation on touch display screen 1705. Operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0197] Optical sensor 1713 is used to collect ambient light intensity. In one embodiment, processor 1701 can control the display brightness of touch display screen 1705 based on the ambient light intensity collected by optical sensor 1713. Specifically, when the ambient light intensity is high, the display brightness of touch display screen 1705 is increased; when the ambient light intensity is low, the display brightness of touch display screen 1705 is decreased. In another embodiment, processor 1701 can also dynamically adjust the shooting parameters of camera assembly 1706 based on the ambient light intensity collected by optical sensor 1713.

[0198] The proximity sensor 1714, also known as a distance sensor, is typically located on the front panel of the computer device 1700. The proximity sensor 1714 is used to detect the distance between the user and the front of the computer device 1700. In one embodiment, when the proximity sensor 1714 detects that the distance between the user and the front of the computer device 1700 is gradually decreasing, the processor 1701 controls the touch display screen 1705 to switch from a screen-on state to a screen-off state; when the proximity sensor 1714 detects that the distance between the user and the front of the computer device 1700 is gradually increasing, the processor 1701 controls the touch display screen 1705 to switch from a screen-off state to a screen-on state.

[0199] Those skilled in the art will understand that Figure 8 The structure shown does not constitute a limitation on the computer device 1700, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0200] This application also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set. When the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor of a computer device, the method for recovering recording data provided in the above-described method embodiments is implemented.

[0201] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the recording data recovery method provided in the above-described method embodiments.

[0202] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0203] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent switching, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for recovering audio recording data, characterized in that, The method includes: The application displays a tuning interface; the tuning interface displays a first recording and a first set of tuning parameters; the first set of tuning parameters is displayed based on the tuning operation of adjusting the first recording; When the tuning interface is displayed, the first recording and the first set of tuning parameters are cached in the buffer area; In response to the application's abnormal exit and subsequent restart, the tuning interface is restored; the tuning interface displays the first recording and the first set of tuning parameters; the first set of tuning parameters is the same as the tuning parameters displayed on the tuning interface before the abnormal exit.

2. The method according to claim 1, characterized in that, The step of caching the first recording and the first set of tuning parameters into the buffer area includes: Create a tuning interface cache folder in the local persistent storage directory of the application; the tuning interface cache folder includes a first file and a second file; The first recording is written to the first file in an incremental appending manner, and the first set of tuning parameters is written to the second file in an overwrite manner; the incremental appending method is used to append the newly written audio data to the end of the existing data in the first file; the overwrite method is used to replace the tuning parameters already stored in the second file with the newly written tuning parameters.

3. The method according to claim 2, characterized in that, The step of writing the first set of tuning parameters into the second file in an overwrite manner includes: In response to receiving a tuning operation, after a preset time has elapsed since the tuning operation was received, the first set of tuning parameters is written into the second file; If a tuning operation is received again within the preset time period, the timer will restart.

4. The method according to claim 2, characterized in that, The method further includes: In response to detecting a change in the lifecycle state of the tuning interface, the first recording and the first set of tuning parameters currently displayed on the tuning interface are written into the buffer; the lifecycle state change includes the tuning interface entering the background state or losing focus.

5. The method according to claim 2, characterized in that, The restoration of the tuning interface includes: The integrity of the first file and the second file in the cache is verified to obtain the verification result. If the verification result indicates that both the first file and the second file are complete, the tuning interface is restored based on the first file and the second file.

6. The method according to claim 5, characterized in that, The method further includes: If the tuning interface cache folder exists, and the first file and the second file are not empty data, and the application records the file path of the first file, then it is determined that both the first file and the second file are complete.

7. The method according to claim 5, characterized in that, The method further includes: If the verification result indicates that a file is missing, the application's homepage will be displayed.

8. The method according to claim 5, characterized in that, The method further includes: If the verification result indicates that the first file is incomplete, the audio data in the first file is truncated to the nearest complete audio frame; The step of restoring the tuning interface based on the first file and the second file includes: The tuning interface is restored based on the truncated first and second files; the duration of the first recording displayed in the restored tuning interface is shorter than the duration of the first recording before the abnormal exit.

9. The method according to claim 5, characterized in that, The method further includes: If the verification result indicates that the second file is incomplete, the stored tuning parameters are parsed from the second file, and the missing tuning parameters are filled with preset default values; The step of restoring the tuning interface based on the first file and the second file includes: The tuning interface is restored based on the first file and the supplemented second file; the first set of tuning parameters displayed in the restored tuning interface includes at least one default value parameter.

10. The method according to any one of claims 5 to 9, characterized in that, The restored tuning interface displays restoration status information; the restoration status information is used to indicate the integrity of the restored first recording and the first set of tuning parameters relative to the state before the abnormal exit.

11. The method according to any one of claims 1 to 9, characterized in that, The method further includes: If the application exits normally, the first recording and the first set of tuning parameters in the cache are cleared.

12. The method according to any one of claims 1 to 9, characterized in that, The application is logged in with a first user account; the method further includes: When the tuning interface is displayed, the cached first recording and the first set of tuning parameters are encrypted and uploaded to the server; The server is configured to synchronize the first recording and the first set of tuning parameters cached in the cloud to the application when the application logged in with the first user account does not detect the first recording and the first set of tuning parameters cached locally.

13. The method according to any one of claims 1 to 9, characterized in that, The method further includes: The method for destroying the page of the tuning interface; If the application exits and the page destruction method is not invoked, it is determined that the application exited abnormally. If the application exits and the page destruction method is invoked, it is determined that the application exited normally.

14. The method according to any one of claims 1 to 9, characterized in that, The response to the application's abnormal exit and subsequent restart, restoring the tuning interface, includes: In response to the application's abnormal exit and subsequent restart, a recovery prompt pop-up window is displayed; the recovery prompt pop-up window is used to ask whether to restore the tuning interface displayed before the abnormal exit. Upon receiving confirmation of the recovery operation via the recovery prompt pop-up, the tuning interface is restored.

15. The method according to any one of claims 1 to 9, characterized in that, The method further includes: When the tuning interface is displayed, recording editing behavior metrics; the editing behavior metrics include at least one of the number of tuning operations and the editing duration of the tuning interface; The value score of the cached data in the cache area is determined based on the editing behavior indicators.

16. The method according to claim 15, characterized in that, The restoration of the tuning interface includes: If the value score is higher than a preset threshold, the tuning interface will be automatically restored. If the value score is not higher than the preset threshold, a recovery prompt pop-up window is displayed; the recovery prompt pop-up window is used to ask whether to restore the tuning interface displayed before the abnormal exit; in response to receiving a confirmation of recovery operation through the recovery prompt pop-up window, the tuning interface is restored.

17. The method according to any one of claims 1 to 9, characterized in that, The method further includes: When the tuning interface is displayed, the received tuning operations are recorded as an operation log; the operation log includes at least one operation record, and each operation record corresponds to one tuning operation; The operation log is stored in a third file in the cache area.

18. The method according to claim 17, characterized in that, The method further includes: In response to the application exiting abnormally and restarting, the operation log is read from the cache. The version selection interface is displayed; the version selection interface displays at least one intermediate editing state, and each intermediate editing state corresponds to an operation record in the operation log. In response to the selection operation of the target intermediate editing state, the tuning interface is restored according to all operation records in the operation log prior to the target intermediate editing state.

19. A device for recovering audio recording data, characterized in that, The device includes: The display module is used to display the tuning interface of the application; the tuning interface displays a first recording and a first set of tuning parameters; the first set of tuning parameters is displayed based on the tuning operation of adjusting the first recording; The caching module is used to cache the first recording and the first set of tuning parameters to the cache area when the tuning interface is displayed; A recovery module is used to restore the tuning interface in response to the application's abnormal exit and restart; the tuning interface displays the first recording and the first set of tuning parameters; the first set of tuning parameters is the same as the tuning parameters displayed on the tuning interface before the abnormal exit.

20. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one program, which is loaded and executed by the processor to implement the method for recovering recording data as described in any one of claims 1 to 18.

21. A computer-readable storage medium, characterized in that, The readable storage medium stores at least one program, which is loaded and executed by a processor to implement the method for recovering recording data as described in any one of claims 1 to 18.

22. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to cause the computer device to perform the method for recovering recording data as described in any one of claims 1 to 18.

Images