Song generation method and program product

Abstract

The present disclosure provides a song generation method and program product, the method comprising: displaying an input area through a graphical user interface; receiving an input instruction for the input area through the graphical user interface to control obtaining an original input text; performing matching processing in a semantic cache according to the original input text to determine a cache matching result, wherein the semantic cache takes semantic features of the original input text as a matching basis; in the case where the cache matching result indicates cache hit, displaying a first song generation result corresponding to the cache matching result through the graphical user interface; in the case where the cache matching result indicates cache miss, displaying a second song generation result through the graphical user interface, wherein the second song generation result is generated based on the original input text. Thus, user inputs with similar semantics can be effectively identified and reused at the cache layer, thereby reducing repeated triggering of complete generation links.

Description

Technical Field

[0001] This disclosure relates to the gaming industry, and in particular to a song generation method and program product. Background Technology

[0002] In music generation games, the common practice is to rewrite the user's input text into lyrics using a language model, and then call a song generation interface to synthesize the lyrics into a song.

[0003] In related technologies, music generation solutions based on natural language processing typically perform text rewriting, lyrics generation, and song synthesis sequentially. The system first submits the user-inputted raw text to a language model, which then stylizes and rewrites it to output the lyrics. The lyrics and style tags are then sent to a song generation interface to obtain the final song asset. To reduce redundant interface calls, some solutions introduce caching mechanisms in this process.

[0004] However, due to the uncertainty of lyric rewriting, the cache aggregation effect is insufficient, resulting in low cache hit rate and low reuse rationality. Summary of the Invention

[0005] The purpose of this disclosure is to provide a song generation method, apparatus, electronic device, and program product to solve the problem that semantic caching mechanisms are difficult to adapt to nondeterministic rewriting, resulting in low reusability.

[0006] In a first aspect, this disclosure provides a song generation method, which provides a graphical user interface through a terminal device. The method includes: displaying an input area through the graphical user interface; receiving an input instruction for the input area through the graphical user interface to control the acquisition of original input text; performing matching processing in a semantic cache based on the original input text to determine a cache matching result, wherein the semantic cache uses the semantic features of the original input text as the matching basis; displaying a first song generation result corresponding to the cache matching result through the graphical user interface when the cache matching result indicates a cache hit; and displaying a second song generation result through the graphical user interface when the cache matching result indicates a cache miss, wherein the second song generation result is generated based on the original input text.

[0007] Optionally, the step of displaying the input area through a graphical user interface includes: displaying the input area and the style selection area through a graphical user interface; the step of receiving input instructions for the input area through a graphical user interface and controlling the acquisition of the original input text includes: receiving input instructions for the input area and the style selection area through a graphical user interface and controlling the acquisition of the original input text and style selection parameters; wherein, the second song generation result is generated based on the original input text and style selection parameters.

[0008] Optionally, the step of generating a second song based on the original input text and style selection parameters includes: if the cache matching result indicates a cache miss, generating target lyrics according to the original input text and style selection parameters and preset conditions, so that the target lyrics cover neighboring inputs with similar semantics to the original input text; and generating a second song corresponding to the target lyrics.

[0009] Optionally, the steps of generating target lyrics according to preset conditions include: selecting target prompt information corresponding to style selection parameters, rewriting the original input text while preserving the intent of the original input text and reducing the degree of literal expression locking, to obtain the target lyrics.

[0010] Optionally, the step of rewriting the original input text to obtain the target lyrics includes: truncating the rewritten text according to a preset syllable count threshold to obtain the target lyrics.

[0011] Optionally, the steps for performing matching in the semantic cache include: determining the target cache partition based on style selection parameters; and performing matching within the target cache partition, wherein the steps for performing matching within the target cache partition include: performing matching within the target cache partition without comparing with other cache partitions, so as to isolate different cache partitions from each other.

[0012] Optionally, the steps of performing matching processing within the target cache partition include: obtaining the current semantic features of the original input text; and comparing the current semantic features with cached semantic features within the target cache partition.

[0013] Optionally, the step of comparing the current semantic feature with the cached semantic features includes: determining the similarity between the current semantic feature and each cached semantic feature; determining a cache hit if the highest similarity reaches a preset similarity threshold; and determining a cache miss if the highest similarity does not reach the preset similarity threshold.

[0014] Optionally, after the step of generating the second song corresponding to the target lyrics, the method further includes: writing the semantic features corresponding to the original input text, the target lyrics, and the second song generation result as a cached data and writing it into the semantic cache.

[0015] Optionally, the step of writing to the semantic cache includes storing the semantic features corresponding to the original input text, the target lyrics, and the second song generation result as an indivisible whole.

[0016] Optionally, the step of generating a second song corresponding to the target lyrics includes: sending the target lyrics and style selection parameters to the song generation interface; and receiving the second song generation result returned by the song generation interface.

[0017] Optionally, the step of displaying the first song generation result or the second song generation result through a graphical user interface includes: displaying a song playback control and a lyrics display area through a graphical user interface; and, upon receiving a trigger operation on the song playback control, playing the first song generation result or the second song generation result and synchronously displaying the corresponding lyrics in the lyrics display area.

[0018] Optionally, the steps of rewriting the original input text to obtain the target lyrics include: calling a preset language model and rewriting the original input text according to the target prompt information within a preset temperature parameter range.

[0019] Optionally, the steps to obtain the current semantic features of the original input text include: calling a local vectorization model to perform vectorization processing on the original input text to obtain the current semantic features.

[0020] Optionally, the step of determining the similarity between the current semantic feature and each cached semantic feature includes: calculating the cosine similarity between the current semantic feature and each cached semantic feature.

[0021] Optionally, the step of determining the target cache partition based on style selection parameters includes: determining the target cache partition and the target similarity threshold corresponding to the target cache partition based on style selection parameters; the step of determining cache hit when the highest similarity reaches the preset similarity threshold includes: determining cache hit when the highest similarity reaches the target similarity threshold.

[0022] Optionally, the step of sending the target lyrics and style selection parameters to the song generation interface includes: removing paragraph marks from the target lyrics to obtain clean lyrics; submitting the clean lyrics and style selection parameters to the song generation interface; wherein, the step of receiving the second song generation result returned by the song generation interface includes: polling the task status of the song generation interface; and if the task is completed, downloading the second song generation result to the local machine.

[0023] Optionally, the step of writing the semantic features corresponding to the original input text, the target lyrics, and the second song generation result into the semantic cache as a cached data item includes: storing the semantic features corresponding to the original input text, the target lyrics, and the second song generation result as atomic pairs in the local storage path.

[0024] Optionally, after the step of displaying the first song generation result or the second song generation result through a graphical user interface, the method further includes: obtaining the first song generation result or the second song generation result and lyrics; assembling and generating a music video based on the first song generation result or the second song generation result and lyrics; and displaying the music video through a graphical user interface.

[0025] Optionally, the step of generating target lyrics according to preset conditions so that the target lyrics cover neighboring inputs with similar semantics to the original input text includes: generating target lyrics that retain the intent of the original input text and are not locked to the literal expression of the original input text, so that the target lyrics can be reused by multiple inputs in the same semantic neighborhood.

[0026] Optionally, the semantic features corresponding to the original input text are written into the semantic cache as the starting point of the new neighborhood; if subsequent inputs hit the semantic cache, the subsequent inputs are assigned to the new neighborhood, so that the neighborhood of the semantic cache can be dynamically expanded as cache entries increase.

[0027] Optionally, the target prompt information is a dedicated prompt information corresponding to the style selection parameters, and different style selection parameters correspond to different dedicated prompt information.

[0028] Optionally, the step of submitting clean lyrics and style selection parameters to the song generation interface includes: submitting the clean lyrics as prompt words, the style selection parameters as tags, and the model parameters and title parameters together to the song generation interface.

[0029] In a second aspect, this disclosure provides an electronic device including a processor and a memory, wherein the processor executes instructions in the memory to perform the steps in the song generation method described in any of the preceding claims.

[0030] Thirdly, this disclosure provides a computer program product, including a computer program that, when executed by a processor, performs the steps in any of the above-described song generation methods.

[0031] This disclosure provides a song generation method, electronic device, and program product. By using the semantic features of the original input text as the matching basis for semantic caching, and displaying the corresponding song generation results in the case of cache hit and miss respectively, user input with similar semantics can be effectively identified and reused in the caching layer, thereby reducing repeated triggering of the complete generation chain. While improving system processing efficiency, it also enhances the user interaction experience through rapid generation result feedback, and enriches the content feedback dimension of music generation games through the result presentation mechanism of hit and miss. Attached Figure Description

[0032] 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.

[0033] Figure 1 A schematic diagram of a system architecture according to an embodiment of this disclosure is shown; Figure 2 A flowchart illustrating a song generation method according to an embodiment of this disclosure is shown; Figure 3 A schematic diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0034] Exemplary embodiments of this disclosure will be described more fully below with reference to the accompanying drawings.

[0035] The accompanying drawings are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

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

[0037] Figure 1A system architecture diagram of the operating environment of this embodiment is shown. This system architecture may include a first client 110, a second client 120, and a server 130. The first client 110 and the second client 120 are terminal devices that have installed and run game client programs, such as mobile phones, tablets, personal computers, smart wearable devices, game consoles, etc. They have display functions and can display a graphical user interface, which may include the operating system interface or the application interface. The first client 110 is the client used by the first game account, and the second client 120 is the client used by the second game account; that is, the game client program running on the first client 110 is logged into the first game account, and the game client program running on the second client 120 is logged into the second game account. The server 130 generally refers to the backend system providing game services in this exemplary embodiment; it can be a single server or a cluster of multiple servers. A game server program is deployed on the server 130 to perform server-side game data processing. The first client 110, the second client 120, and the server 130 can be connected via wired or wireless communication links for data transmission. For example, the first client 110 can send information (such as an editing assistance request) to the second client 120 through the server 130, and the second client 120 can send information (such as an edited first game lineup) to the first client 110 through the server 130. In addition, the first client 110 and the second client 120 can also communicate directly through wired or wireless means.

[0038] In one implementation, the above method can be implemented and executed based on a cloud interaction system. The cloud interaction system can be based on the aforementioned system architecture. Various cloud applications can run under the cloud interaction system, such as cloud gaming. Taking cloud gaming as an example, cloud gaming refers to a gaming method based on cloud computing. In the cloud gaming operating mode, the game program's execution and the game screen presentation are separated. The storage and execution of in-game control and interaction methods are completed on the cloud gaming server (such as the aforementioned server 130). The cloud gaming client (such as the aforementioned first client 110 and second client 120) includes receiving and sending data, as well as presenting the game screen. For example, the cloud gaming client can be a display device with data transmission capabilities located close to the user, such as a mobile terminal, television, computer, or PDA; while the cloud gaming server in the cloud performs information processing. When playing or editing, the player operates the cloud gaming client to send operation commands to the cloud gaming server. The cloud gaming server runs the game according to the operation commands, encodes and compresses game screen data, returns it to the cloud gaming client via the network, and finally decodes and outputs the game screen through the cloud gaming client.

[0039] The example provides a song generation method. Figure 2 This is a flowchart of a song generation method according to an embodiment of the present disclosure, such as... Figure 2 As shown, the process includes the following steps: Step S110: Display the input area through the graphical user interface; Step S120: Receive input instructions for the input area through the graphical user interface to control the acquisition of the original input text; Step S130: Based on the original input text, perform matching processing in the semantic cache to determine the cache matching result, wherein the semantic cache uses the semantic features of the original input text as the matching basis; Step S140: If the cache matching result indicates a cache hit, the first song generation result corresponding to the cache matching result is displayed through the graphical user interface; In step S150, if the cache matching result indicates a cache miss, the second song generation result is displayed through a graphical user interface, wherein the second song generation result is generated based on the original input text.

[0040] The method provided in this embodiment enables the system to perform matching processing in the semantic cache based on semantic features after the user inputs text. When the cache is hit, the first song generation result is returned directly; when the cache is not hit, the second song generation result is generated based on the original input text and displayed. This achieves the reuse of song generation results at the semantic level, reducing the perceived time for users to repeatedly wait for the generation of the same or similar semantic content, and improving the interactive experience. At the same time, the semantic caching mechanism supports the rapid retrieval and reuse of different song generation results corresponding to multiple semantically similar inputs, enriching the input semantic space and the diversity of output song content in interactive application scenarios, and improving the richness of the game. In addition, the semantic-level cache matching processing replaces the repeated song generation calculation, significantly reducing the frequency of calls to high-cost generation interfaces and the consumption of system computing resources, effectively solving the problem of excessive resource overhead for generation services in the computer field.

[0041] The steps described above are explained in detail below.

[0042] In step S110, the input area is displayed via a graphical user interface. In application, a graphical user interface is provided through a terminal device. Specifically, a corresponding application runs on the terminal device's operating system to generate and display the graphical user interface, and loads and displays the input area within a preset interactive area of ​​the graphical user interface, providing the user with a text input entry point.

[0043] The input area is used to receive text content entered by the user. This can be a single-line text input box, a multi-line text editing area, or an input panel with placeholder text. The input area can be an editable text window that floats in the graphical user interface; the user can click to bring up this floating input panel and type the text content for which they want to generate a song. Alternatively, the input area can be a full-width text bar occupying a fixed area at the bottom of the graphical user interface, equipped with a submit trigger button; the user can swipe to bring up the bottom input bar, enter text, and trigger the input command.

[0044] The embodiments of this application are not limited to the specific form of the input area, such as a floating window, a fixed bottom bar, or other text input interaction entry points.

[0045] In step S120, input instructions for the input area are received through the graphical user interface to control the acquisition of the original input text.

[0046] Specifically, the system listens for user input commands issued in the graphical user interface for the input area, reads the original input text from the input area, and uses it as the basis for subsequent song generation and cache matching.

[0047] Input commands are used to initiate the text capture process. These can be, for example, a text confirmation command triggered by clicking an input area, a command to bring up the input panel and submit content triggered by a swipe, or an automatic retrieval command initiated after speech-to-text conversion. For instance, a user triggers an input area and submits text in the graphical user interface by clicking; the system responds to this click by receiving the input command and retrieving the original input text. Similarly, a user long-presses an input area on a smartphone's touchscreen; the system detects this long-press gesture and automatically captures the original input text already entered within that area. Furthermore, a user clicks the submit button on the right side of the interface; the system receives this click command and extracts all text from the input area as the original input text.

[0048] The embodiments of this application are not limited to the triggering method of input commands, such as clicking, swiping, long pressing or button confirmation.

[0049] The raw input text is the initial natural language text content entered by the user through the input area, without semantic transformation or rewriting. For example, it can be a single sentence of natural language description, a combination of phrases containing punctuation, or text content carrying sentiment tags. For instance, if a user enters a short sentence expressing their current mood in the input area, the system will use this short sentence as the raw input text for cached matching. Similarly, if a user sequentially enters multiple descriptive words in the input area, the system will acquire the entire text composed of these words as the raw input text and use it for subsequent semantic analysis.

[0050] The embodiments of this application are not limited to the specific form of the original input text, such as short sentences, keyword combinations, or tagged text.

[0051] In step S130, matching is performed in the semantic cache based on the original input text to determine the cached matching result. The semantic cache uses the semantic features of the original input text as the matching basis.

[0052] Specifically, the system extracts semantic features from the acquired original input text and performs matching processing in a pre-built semantic cache. By comparing the similarity of semantic features, it determines whether there is already a matching song generation content in the cache, and obtains a cache matching result indicating whether the cache has been hit or not.

[0053] Semantic caching is used to store historical song generation data and indexes it with semantic features. This can be, for example, an in-memory database based on vector similarity retrieval, a distributed cache organized by semantic neighborhood, or a combination of local files and indexes. For instance, the system partitions a dedicated cache area on the local disk, storing the paths of historically generated song files and their corresponding semantic vectors as entries for subsequent similarity matching queries. Alternatively, the user's original input text is vectorized and uploaded to the server; the server then retrieves the historical cache entry in the cache cluster that is closest to that vector and returns the matching result.

[0054] The embodiments of this application are not limited to the deployment form of semantic caching, such as local key-value caching, server-side high-speed cache cluster, or a combination of both.

[0055] Matching is used to compare the similarity between the original input text and historical cached data based on semantic features in the semantic cache. This can be retrieval comparison based on vector similarity calculations, fast filtering based on semantic feature hash values, or range queries based on semantic neighborhood affiliation. For example, the system extracts the current semantic representation of the user input, calculates the similarity between this representation and existing semantic features in the cache, and determines the cached matching result by comparing whether the highest similarity score meets the matching criteria. Alternatively, the system determines the target retrieval range based on the attribute category of the current input and performs semantic feature comparison only within this range.

[0056] The embodiments of this application are not limited to the retrieval strategy of matching processing, such as global one-to-one comparison, local range retrieval or a hybrid strategy.

[0057] Semantic features are used to characterize the semantic connotation of text and measure the similarity between texts. These can be high-dimensional vectors obtained through vectorization models, sparse vectors generated based on word frequency statistics, or context-aware vectors encoded through language models. For example, the system calls a text analysis model to convert a user-inputted sentence into fixed-dimensional vector data as semantic features; or, the system segments the user-inputted text into words, constructs word frequency vectors, and performs weighted processing based on a pre-defined lexicon to obtain semantic feature vectors that can be used for similarity comparison.

[0058] The embodiments of this application are not limited to the method of extracting semantic features, such as dense vectors, sparse vectors, or a combination of both.

[0059] The matching criteria are similarity measures used to determine the degree of semantic association between the original input and the cached data. These can be, for example, distance thresholds in vector space, cosine similarity standards of semantic feature vectors, or classification matching rules based on semantic equivalence. For instance, the system sets a similarity reference value as the matching criterion; when the semantic feature similarity between the current input and a historical cached data is greater than or equal to this reference value, a cache hit is determined. Alternatively, the system automatically calculates a recommended reference value based on the current data distribution; a similarity better than this value is considered a hit.

[0060] The embodiments of this application are not limited to specific standards for matching, such as fixed thresholds, dynamic thresholds, or hierarchical thresholds.

[0061] The cache matching result indicates whether the original input text has been hit or not in the cache. This can be structured data containing a hit flag and the corresponding cache entry identifier, a boolean status value indicating only whether a hit occurred, or a multi-level matching report with a similarity score. For example, after retrieving data from the semantic cache, the system generates structured data containing a status flag and an entry number. If the status flag indicates a hit, the system retrieves the corresponding first song based on the entry number. Alternatively, after completing the semantic comparison, the system outputs an enumerated status code, which the front-end interface uses to determine whether to display a cached song or initiate a new song generation request.

[0062] The embodiments of this application are not limited to the output format of cached matching results, such as structured data, status codes or similarity reports.

[0063] In step S140, if the cache matching result indicates a cache hit, the first song generation result corresponding to the cache matching result is displayed through the graphical user interface.

[0064] Specifically, when the system determines that the cache has been hit, it retrieves the first song generation result corresponding to the cache matching result from the semantic cache and presents it to the user through the graphical user interface.

[0065] A cache hit refers to a situation where the semantic features of the original input text match the semantic features of a historical data entry in the semantic cache according to a specified standard. For example, if a user inputs a sentence expressing a happy mood, the system calculates that its semantic vector has a similarity of 0.82 with a cached entry, exceeding the set threshold of 0.7, thus determining a cache hit and retrieving the corresponding song. Similarly, if a user inputs another sentence with slightly different expression but the same semantic meaning, the system confirms through semantic feature comparison that the two belong to the same semantic neighborhood, thus determining a cache hit.

[0066] The embodiments of this application are not limited to the cache hit determination method, such as similarity threshold triggering, semantic neighborhood attribution or dynamic standard adaptation.

[0067] The first song generation result is historical song generation data that matches the semantics of the original input text and is already stored in the cache. This data could include a combination of audio file paths and lyrics, a pre-rendered song media stream, or a song playback resource package with lyrics display. For example, if a previous user input similar semantic text, generating a song and storing it as a media file, and the current user inputs semantically similar text, triggering a cache hit, the system returns the song file path and corresponding display data and displays it on the interface. Alternatively, the semantic cache stores data addresses pointing to server-side storage resources; upon a hit, the system retrieves the audio based on that address and plays it to the user in the graphical user interface.

[0068] The embodiments of this application are not limited to the storage format of the first song generation result, such as local files, cloud links, or pre-rendered media streams.

[0069] In step S150, if the cache matching result indicates a cache miss, the second song generation result is displayed through a graphical user interface, wherein the second song generation result is generated based on the original input text.

[0070] Specifically, when the cache misses, the system initiates a new song generation process based on the original input text, obtains a second song generation result, and presents it to the user through a graphical user interface.

[0071] A cache miss occurs when the semantic features of the original input text do not match the semantic features of any historical data in the semantic cache, failing to meet the standards specified by the matching criteria. For example, if a user inputs text with a completely new semantic topic, the system may find, after traversing the semantic cache, that the highest similarity score is far below the set standard, thus determining a cache miss and initiating a new song generation process. Alternatively, if the semantic cache is empty upon the application's initial launch, the first piece of text entered by the user may be determined to be a cache miss during matching, triggering the generation of a new song based on that original input text.

[0072] The embodiments of this application are not limited to the cache miss determination method, such as insufficient similarity, no data in the partition, or empty cache.

[0073] The second song generation result is new song data generated in real time based on the original input text. This could be an audio file returned from an external song generation interface, audio data rendered in real time by a local song generation engine, or a song asset synthesized from the original input text after lyrics rewriting. For example, after a user enters text in the graphical user interface, the system determines that the cache has not been hit, and then calls the cloud-based song generation interface to submit the text. After the interface returns the generated audio, it is downloaded to the local machine and displayed as the second song generation result. Alternatively, after confirming a cache miss, the system inputs the original input text into a local music generation model, which then infers and generates a new song that matches the semantics of the text in real time and saves it as the second song generation result.

[0074] The embodiments of this application are not limited to the generation method of the second song generation result, such as cloud interface generation, local model rendering, or hybrid synthesis.

[0075] It should be noted that in this embodiment, the received original input text can be sent to the server, where it can be matched, the first song can be returned, or a second song can be generated.

[0076] In other implementations, the matching process, returning the first song, or generating the second song can be performed locally.

[0077] The appeal process can also be carried out in different stages on the server and on the local client, depending on the actual engineering needs.

[0078] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0079] When a user launches the application on their terminal device, the input area is displayed after the graphical user interface (GUI) loads. The user enters text in this area and issues an input command. The system retrieves the original input text, extracts its semantic features, performs a matching process in the semantic cache, determines a cache miss, and then generates a second song based on the original input text, which is displayed in the GUI. Subsequently, another user enters semantically similar text in the same application's input area and issues an input command. The system retrieves the original input text, performs a semantic cache matching, determines a cache hit, and directly displays the first song generation result. This first song generation result corresponds to the same historical cached content as the previously generated second song generation result, thus allowing different semantically similar inputs to reuse the same song generation result.

[0080] In this embodiment, the terminal can synchronously acquire style selection parameters and use them for song generation in the following way: display the input area and style selection area through the graphical user interface, receive input instructions for these two areas, and control the acquisition of the original input text and style selection parameters, wherein the second song generation result is generated based on the original input text and style selection parameters.

[0081] The method provided in this embodiment simultaneously displays the input area and style selection area on the graphical user interface, enabling users to complete text input and style specification in a single interaction process. This avoids interface jumps and waiting delays caused by step-by-step operations, thereby improving the interactive experience. By using style selection parameters and the original input text as dual bases for cache matching and song generation, the same semantic content can be mapped to song outputs of different style categories, enriching the dimensions and diversity of the generated results and thus enhancing the game's richness. By collecting style selection parameters at the input stage and integrating them into cache partition retrieval and backend generation calls, cache comparison is performed only within the target partition, and the generated results strictly follow the user's selected style. This effectively avoids invalid interface calls caused by cross-style misuse and style mismatch, significantly reducing resource consumption in the high-cost generation process and solving problems in the computer field.

[0082] The above plan will be explained in detail below.

[0083] The terminal displays both an input area and a style selection area on the graphical user interface. The style selection area is used to simultaneously collect the user's song style preferences during the text input stage. The collected results are sent to the backend along with the original input text, serving as the basis for cache partition positioning and song-oriented generation.

[0084] Taking interface layout as an example, the style selection area can be a horizontal navigation bar placed above the input area. This navigation bar contains multiple selectable labels representing different music genres, such as "Pop," "Rock," and "Electronic." Before entering text, the user can directly click to switch to the target style label, and the terminal will then record the corresponding style selection parameters. This layout eliminates the need to navigate to a different page and does not interrupt the input process.

[0085] To further illustrate, the terminal can also configure an expandable style selection overlay next to the input area. For example, after the user completes text input, long-pressing the input area or clicking the style icon in the lower right corner of the interface will cause a half-screen overlay to slide out on the right side of the interface, displaying various music style options in a grid card format. After the user selects the desired style and clicks confirm to submit, the terminal simultaneously obtains the original input text and the corresponding style selection parameters, realizing an interactive process of inputting first and then selecting the style. The above is only an example, and this embodiment does not impose any limitations on it.

[0086] In one specific application, the terminal simultaneously displays an input area and a style selection navigation bar above it on the graphical user interface. The user types a sample text in the input area and clicks the "Electronic" style label in the navigation bar. The graphical user interface then synchronously displays the input area and the selected style indicator.

[0087] The terminal simultaneously monitors operation events in both the input area and the style selection area via a graphical user interface. After the user completes text entry and style selection, the terminal receives the corresponding input instructions. It retrieves both the original input text entered in the input area and the style selection parameters chosen by the user in the style selection area, using both as the combined basis for subsequent cache matching and song generation. The resulting song is generated not only based on the semantic content of the original input text but also on the style type indicated by the style selection parameters.

[0088] The style selection parameter is a data identifier representing the user's desired song style category. It is passed to the backend along with the original input text, serving as the dual basis for cache partitioning and song generation. For example, it can be a system-predefined enumerated style code, with each code uniquely corresponding to a song style category. Assuming that after the user selects the target style on the front-end interface, the terminal records the style selection parameter as the corresponding enumerated code while obtaining the original input text. Subsequent cache judgment and song generation are both performed based on this code.

[0089] For example, the style selection parameter can also be a text tag carrying style semantic information. When the terminal matches the cache, it parses the tag into the corresponding partition identifier; if the cache is not hit, the tag is submitted to the song generation interface along with the target lyrics to indicate the generation of a second song with the corresponding style.

[0090] In one exemplary application of this embodiment, the terminal device simultaneously displays an input area and a style selection navigation bar above it on a graphical user interface. The user inputs a sample text and clicks the target style tag. After receiving the input instruction, the terminal device controls the acquisition of the original input text and style selection parameters. If the cache is not hit in the future, the terminal device generates a second song based on the original input text and style selection parameters and displays it through the graphical user interface.

[0091] In one possible implementation, the steps of performing matching processing in the semantic cache described above may include: Step S210: Select parameters according to style to determine the target cache partition; Step S220: Perform matching processing within the target cache partition. This matching processing within the target cache partition includes: performing matching within the target cache partition without comparing with other cache partitions, thereby isolating different cache partitions from each other.

[0092] The method provided in this embodiment introduces a target cache partition determination mechanism based on style selection parameters into the semantic cache, and performs mutually isolated matching processes within the target cache partition. This avoids cross-interference between different styles, thereby improving the user's interactive experience in obtaining the target style song generation results, ensuring the accuracy and richness of cache reuse in multi-style scenarios, reducing the invalid computational overhead in the cache matching process, and solving the cache matching efficiency problem caused by cross-style misuse.

[0093] The above plan will be explained in detail below.

[0094] In step S210, the target cache partition is determined based on the style selection parameters.

[0095] In this context, a cache partition is an independent storage unit after the semantic cache is divided according to predetermined dimensions. For example, the semantic cache can be divided into multiple parallel storage buckets according to music style, with each bucket independently holding historical semantic features and song generation results data for its corresponding style. For instance, the overall architecture of the semantic cache has five style storage buckets, corresponding to cute and catchy, rhythmic hip-hop, emo pop, abstract electronic music, and energetic pitch variation, respectively. Data entries within each bucket are generated and accumulated only within the style dimension to which that bucket belongs. Optionally, the cache partition can also be a sharded database horizontally partitioned by style tags on distributed nodes. Each shard is associated with the central routing table through a style identifier, and a single shard failure does not affect the global cache service. This application embodiment does not limit this approach.

[0096] In one possible implementation, the target cache partition is a pre-divided independent storage sub-region based on music style, uniquely bound to a single style selection parameter. Different style-related partitions are physically or logically isolated. For example, when a user submits raw input text in the input area and selects the "Rhythm Hip Hop" style, the system routes the request to the "Rhythm Hip Hop" cache partition, strictly limiting the query to the subset of data belonging to that style, thus avoiding cross-interference with data from other styles.

[0097] In another embodiment of this application, the target cache partition is a dynamic logical shard associated with style selection parameters through an index mapping. This shard is dynamically mounted and unmounted at runtime based on style tags, ensuring that historical cached data of the same style falls into the same logical address space. For example, when the style selection parameter is parsed as a dynamic pitch change tag, the system locates the logical shard address corresponding to the tag through the index mapping and traverses the cached historical data entries only within that shard to complete the matching query task.

[0098] Optionally, the target cache partition can also be divided according to the release year of the song, mood tags, or user group preference categories, which is not limited in this embodiment.

[0099] In step S220, matching is performed within the target cache partition.

[0100] This step performs cache matching within the identified target cache partition without extending the query scope to other cache partitions, thus maintaining isolation between partitions with different styles. The matching process involves comparing the current input with historical data stored in the target cache partition to determine the degree of similarity.

[0101] In one possible implementation, matching is a comparison operation based on semantic similarity calculation. For example, after the system uses the player's original text as the matching basis, it only performs semantic similarity comparison and determines the hit status within the "cute and brainwashing" section, and the traversal range does not exceed the boundary of this section to ensure the local consistency of the retrieval results.

[0102] In another embodiment of this application, matching is performed as an approximate retrieval based on a fast index structure. For example, the system quickly locates a potential candidate set within an abstract electronic music partition using independent index instances bound to the style selection parameter, and then performs fine-grained filtering within that candidate set, thereby reducing the performance overhead of a full scan.

[0103] It should be noted that "other cache partitions" refer to non-target cache areas that store historical data of different categories, outside the style dimension corresponding to the current matching request. If a bucket architecture is used, "other cache partitions" refer to parallel buckets with different style tags within the same semantic cache, which are explicitly skipped during the matching phase. If a sharded database is used, "other cache partitions" refer to non-target shards distributed across different physical nodes, which are filtered during the routing phase, and their node addresses are removed from the routing candidate list for this query.

[0104] Therefore, by strictly limiting the search scope to the target cache partition and excluding other cache partitions, each style partition is independent of each other in terms of data path and computational logic. Optionally, this mutual isolation can be achieved by disabling cross-partition broadcast queries, that is, the query scheduler performs hard routing at the request entry point based on the style identifier, initiating matching calculations only in the single storage bucket corresponding to the target cache partition, thus preventing lateral penetration. Optionally, different cache partitions can also be divided in terms of memory address space or database access permissions, so that each partition within the same process occupies an independent address range, and data reading from unauthorized partitions is prevented through access permission checks, achieving isolation at the storage level. This application does not limit this aspect.

[0105] In an exemplary application of this embodiment, the user submits original input text in the input area of ​​the graphical user interface and selects the cute and brainwashing style. The system determines the cute and brainwashing partition in the semantic cache as the target cache partition according to the style selection parameter. Then, cache matching is performed only within this partition, without extending the comparison range to other cache partitions, thereby ensuring that different style partitions are isolated from each other, so that the cache matching result is generated only in the data subset of the cute and brainwashing style.

[0106] In some embodiments, when the terminal performs matching processing in the target cache partition, it can obtain and compare semantic features in the following way: obtain the current semantic features of the original input text and compare them with the cached semantic features in the target cache partition.

[0107] The method provided in this embodiment enables the rapid extraction of current semantic features from the original input text and comparison with historical cache semantic features when performing matching processing based on semantic features within the target cache partition. By combining partition isolation with semantic matching, the retrieval method not only improves the interactive experience and enhances the richness of the game, but also solves the computer field problems of low cache retrieval efficiency and cross-style misuse, effectively supporting the rapid determination of cache hits and misses.

[0108] The above plan will be explained in detail below.

[0109] The current semantic features are used to represent the core semantic information of the original input text, and are usually represented in vector form. After receiving the original input text, the terminal can call the locally deployed vectorization model to encode it and generate a dense vector of fixed dimensions. Taking the example of a user inputting "It's so cool to turn the tables" through the graphical user interface and selecting the cute and brainwashing style, the terminal performs vectorization processing on the original input text to obtain the corresponding current semantic features, and then can enter the cute and brainwashing section to prepare for comparison.

[0110] Cached semantic features refer to the baseline feature vectors stored in the target cache partition after semantic encoding of previous input requests. These vectors are typically stored in association with the lyrics text and song file paths within that partition. These feature data are maintained independently by style partition, with no interference between partitions, and can be dynamically appended as new requests are processed. For example, the "Cute and Catchy" partition may already contain semantic features generated from a previous user input; when a new user inputs semantically similar text, the terminal uses these historical semantic features as a comparison benchmark.

[0111] To further illustrate, the comparison process involves measuring the similarity between the current semantic feature and each cached semantic feature within the target cache partition. Based on the comparison results between the current semantic feature and the cached semantic features, the terminal determines whether the current input should be included in an existing semantic neighborhood and triggers cache reuse. For example, the terminal can quickly assess semantic similarity through vector inner product operations, or accelerate large-scale feature comparison through an approximate nearest neighbor search algorithm. Continuing with the "cute and catchy" partition as an example, the terminal evaluates the semantic features of the user's current input against the cached semantic features in that partition one by one. If the evaluation result shows that the current input is sufficiently close to a historical cached semantic feature, the corresponding song and lyrics are directly returned to the graphical user interface. If no sufficiently close semantic feature is found, it is determined that the cache has not been hit, and the subsequent generation process begins.

[0112] In some embodiments, the terminal may obtain the current semantic features of the original input text by calling a local vectorization model to perform vectorization processing on the original input text and obtain the current semantic features.

[0113] The method provided in this implementation enables vectorization of the original input text by calling a vectorization model locally on the terminal, effectively reducing reliance on external network services and transmission latency, thereby improving the real-time response capability of semantic feature extraction. After players input text, they can enter the cache matching stage more quickly, shortening the waiting time from request submission to result presentation and improving the interactive experience. At the same time, the reliable local semantic feature generation capability supports the semantic cache to cover and reuse diverse input expressions, expanding the demand scenarios that the song generation results can serve and enriching the diversity of content generation. In addition, this solution solves the network latency and single point of failure risks in the cache matching pre-stage due to reliance on remote embedding interfaces, enhancing the robustness and availability of the system in weak network or offline environments.

[0114] The above plan will be explained in detail below.

[0115] The local vectorization model is deployed on the terminal or local server, directly receiving the raw input text and outputting the corresponding semantic features without needing to establish a data connection with a remote server. For example, in a mobile song generation application, a terminal-side embedded component based on the MiniLM architecture can be built in; when the player inputs a mood phrase in the front-end input area, this component directly completes forward inference locally and outputs a fixed-dimensional semantic vector.

[0116] For scenarios with limited local computing power, the aforementioned vectorization model can also be quantized and pruned using INT8 to adapt to terminal or hardware constraints. Taking in-vehicle music generation as an example, the quantized multilingual embedding model deployed locally in the vehicle's infotainment system can still encode the free text input by drivers and passengers into low-precision semantic vectors in real time, even in unstable network environments such as tunnels, ensuring the continuous progress of the semantic cache matching process.

[0117] In the vectorization process, the local vectorization model first performs word segmentation and adds position tags to the text, and then outputs sentence-level semantic features through multi-layer feature abstraction and information aggregation.

[0118] To further illustrate, the vectorization model optimized based on the contrastive learning objective is optimized during training by narrowing the vector distance between synonymous expressions and widening the vector distance between irrelevant semantics. This ensures that when a player inputs "I'm so happy to turn the tables," the resulting semantic feature is closer in space to the previously cached vector corresponding to "It's so awesome to turn the tables today." As a result, it is recognized as a semantically similar input in subsequent comparisons, supporting cache hit determination.

[0119] The above is merely an example, and no limitation is made in this embodiment.

[0120] In an exemplary application of this embodiment, a player enters the text "Today's comeback was so awesome" in the input area of ​​the graphical user interface. After receiving the input command, the terminal device immediately calls the local vectorization model to vectorize the original input text and obtain the corresponding current semantic features. Next, the system uses the current semantic features to compare with the cached semantic features in the target cache partition. When there is no historical cached data in the partition, it is determined that the cache has not been hit. The system continues to generate a second song based on the original input text and displays it through the graphical user interface.

[0121] After obtaining the current semantic feature, the terminal can compare the feature with the cached semantic features in the target cache partition in the following way: determine the similarity between the current semantic feature and each cached semantic feature; if the highest similarity reaches the preset similarity threshold, the cache is determined to be hit; if the highest similarity does not reach the preset similarity threshold, the cache is determined to be hit.

[0122] The method provided in this embodiment establishes a quantitative standard for matching judgment of semantic cache. By comparing similarity and determining thresholds, reusable historical generation results are identified while preserving the original input semantics, thereby reducing the call frequency of the song generation interface and ensuring the semantic consistency of the returned results.

[0123] For example, similarity is used to measure the proximity of current semantic features to cached semantic features in the semantic space. In practical applications, similarity calculation can include, but is not limited to, at least one of the following: vector space metrics based on Euclidean distance or Manhattan distance, and association metrics based on the intersection ratio of key semantic labels. The above methods can be used individually or in a weighted combination.

[0124] For example, after converting the text input by the player into a semantic vector, the spatial distance between this vector and each historical cached vector is calculated within the current style partition; or, the core semantic label set of the current input and the cached input is extracted, and the quantitative value of the semantic matching degree is obtained by calculating the intersection ratio of the two on the key intent labels.

[0125] Furthermore, the terminal determines the highest similarity score from the calculated similarity scores. This highest similarity score can be determined by taking the maximum value after traversing all cached records within the partition, or it can be quickly determined by sorting the cached records by similarity and taking the first one in the queue.

[0126] A preset similarity threshold is used to determine whether the current input and the historical cached input belong to the same semantic neighborhood. This threshold can be a fixed numerical boundary pre-configured by the system for different style partitions, a dynamic value that is adaptively updated based on historical hit data statistics, or a combination of a fixed threshold and a dynamic correction coefficient.

[0127] In one specific application, when a player inputs a phrase related to turning the tide and selects the corresponding style, the terminal calculates the similarity between the current semantic feature and all cached semantic features within that partition, determining the highest similarity to be 0.82. Since this value reaches the preset similarity threshold of 0.7, the terminal determines that the cache has been hit and directly returns the corresponding cached song generation result and lyrics to the player.

[0128] In another specific application, when a player inputs a sentence describing a specific mood and selects the corresponding style, if the highest similarity between the current semantic feature and all cached semantic features in that partition is only 0.45, which does not reach the preset similarity threshold of 0.7, the terminal determines that the cache has not been hit and triggers the subsequent lyrics rewriting and song generation process.

[0129] In one possible implementation, when comparing the current semantic feature with cached semantic features within the target cache partition, determining the similarity between the current semantic feature and each cached semantic feature includes: Step S310: Calculate the cosine similarity between the current semantic feature and each cached semantic feature.

[0130] Specifically, after obtaining the current semantic features corresponding to the original input text, the cosine similarity between the current semantic features and each cached semantic feature in the target cache partition is calculated to obtain the directional proximity between the two in the vector space, and the semantic proximity relationship is determined accordingly.

[0131] The embodiments of this application are not limited to the method of measuring semantic similarity, and may also include Euclidean distance, Pearson correlation coefficient, Manhattan distance, etc.

[0132] In one possible implementation, the step of determining the target cache partition based on the style selection parameters described above may include: Step S410: Select parameters according to style to determine the target cache partition and the target similarity threshold corresponding to the target cache partition; The steps described above for determining a cache hit when the highest similarity reaches a preset similarity threshold may include: Step S420: If the highest similarity reaches the target similarity threshold, a cache hit is determined.

[0133] The method provided in this implementation introduces a target similarity threshold corresponding to the target cache partition during the cache matching process. By configuring differentiated hit judgment criteria for different style partitions, it solves the computer domain problem that a unified threshold is difficult to adapt to the semantic distribution differences under different styles, making cache hit judgment more accurate. Players' similar semantic inputs under the same style are more likely to be reused reasonably, reducing unnecessary song generation interface calls, thereby improving the smoothness of the interactive experience. At the same time, the isolation effect of independent thresholds between different styles forms a richer diversity of generation results, enhancing the richness of the game.

[0134] The above plan will be explained in detail below.

[0135] In step S410, the system configures differentiated similarity thresholds for different style partitions, replacing the uniform preset threshold. The target similarity threshold is used to control the semantic hit boundary of the corresponding partition. Optionally, this threshold can be initially configured based on the semantic dispersion of historical inputs under a style, dynamically corrected based on hit feedback, or manually specified by the management terminal.

[0136] As an example, the target similarity threshold can be dynamically configured according to the style attribute. For example, the threshold is set to 0.75 for the cute and catchy style category and 0.68 for the rhythmic hip-hop style category, in order to adapt to the semantic divergence of player input under different styles and reduce the probability of false hits across categories.

[0137] As another example, the target similarity threshold can also be set as an adjustable parameter that maps one-to-one with the cached partitions. For example, the threshold for the Emo Popularity partition is configured to 0.72, which only returns a hit result when the highest cosine similarity with the cached vector is not less than 0.72, ensuring the rationality of reuse.

[0138] It should be noted that the two configuration methods mentioned above can be used individually, or can be dynamically switched or combined among multiple methods based on real-time statistical data.

[0139] In step S420, as an example, if the highest cosine similarity in the current style partition is 0.82 and the corresponding target similarity threshold is 0.70, the system determines that the cache has been hit, directly retrieves the song file path associated with the cached entry and the lyrics, assembles them and returns them to the front end for playback, skips the lyrics rewriting and song generation process, and returns the first song generation result through the graphical user interface. The corresponding hip-hop style song is played by the song playback control, and the lyrics are displayed synchronously in the lyrics display area.

[0140] In one possible implementation, the step of generating a second song based on the original input text and style selection parameters may include: Step S510: If the cache matching result indicates that the cache was not hit, select parameters according to the original input text and style, and generate target lyrics according to preset conditions so that the target lyrics cover the neighboring inputs that are semantically similar to the original input text. Step S520: Generate the second song generation result corresponding to the target lyrics.

[0141] The method provided in this embodiment enables the generation of target lyrics by applying preset conditions to cover semantically similar neighboring inputs when the cache is not hit. This transforms the non-deterministic lyrics rewriting process into a reusable intermediate product, solving the problem in the prior art where cache objects and inputs are in one-to-one correspondence and cannot be reasonably reused. When players trigger semantically similar inputs through the graphical user interface, subsequent requests can hit the cache and quickly return the song generation result, significantly improving the interactive experience and response efficiency. At the same time, since one set of target lyrics can serve a class of semantically similar inputs, it effectively expands the reuse dimension and richness of song content. In addition, by using the target lyrics as an intermediate anchor point for cache reuse, the number of calls to the high-cost song generation interface is greatly reduced, lowering system resource consumption and call costs, and solving the computer domain cost and efficiency problems in the music generation chain.

[0142] The above plan will be explained in detail below.

[0143] Preset conditions refer to generation rules that preserve the core intent of the original input text during the rewriting process while reducing the degree of fixation on literal expression. These rules, combined with style selection parameters, abstract the original input, allowing the rewritten lyrics to be reused by various semantically similar inputs. In one possible implementation, preset conditions can be a set of constraints that abstractly rewrite the original input text based on its core intent and the expression paradigm corresponding to the style selection parameters. For example, when a player inputs "Victory in battle, so happy!" and selects a cute style, the system transforms this input into generic lyrics that retain the joyful emotion but don't directly copy the original words (such as "The little hero defeated the monster, I'm overjoyed!"). This lyric can then be reused when the player subsequently inputs "Finally won, so happy!"

[0144] In another embodiment of this application, the preset conditions can also be constraints on the combination of prosodic features and rhythm type of the recombined text based on the style selection parameters. For example, when a player inputs a sentence describing a battle victory and selects a fast-paced style, the system recombines it into short, rhyming, and rhythmic general lyrics for reuse by subsequent inputs with similar semantics in the same style.

[0145] It should be noted that the above preset conditions can be used individually or in combination, and this application embodiment does not limit this.

[0146] Here, the target lyrics refer to the singable text that has been rewritten under preset constraints and serves as an intermediate medium for song generation. In one possible implementation, the target lyrics can be a singing script containing verses and choruses, which is divided into different singing segments based on style selection parameters for synchronous segmented display during playback.

[0147] Optionally, the target lyrics can also be continuous lyrics text after removing paragraph marks. When displayed, the current sung sentence is dynamically shown according to the playback progress, and it is sent as a whole into the song generation process during the generation stage to adapt to the continuous singing structure.

[0148] Here, semantic similarity refers to the semantic association that measures the degree of similarity between different input texts at the meaning level, serving as a criterion for cache matching and reuse. In one possible implementation, semantic similarity can be a matching relationship based on consistent emotional polarity and overlapping topic tags. This matching relationship groups inputs expressing similar emotions into the same reuse group by comparing the emotional tendency of the input text with its corresponding topic. For example, if a player inputs multiple colloquial phrases expressing happiness, the system determines that these inputs have the same emotional polarity and consistent topic, thus including them in the same lyrics reuse scope to reduce duplicate generation.

[0149] In another embodiment of this application, semantic similarity can also be a determination relationship based on the intersection of core keyword sets and the absence of deviation in overall intent. This determination relationship is achieved by extracting key semantic units from the input and comparing the degree of overlap to determine whether different inputs point to the same need. For example, if different players input short phrases containing keywords such as "comeback" or "counterattack," the system determines that the two are semantically similar based on the intersection of core words, allowing subsequent inputs to reuse previously generated target lyrics and songs.

[0150] Here, neighborhood input refers to the set of neighboring inputs that fall within the same semantic coverage as the original input text and can be used for the same target lyrics. In one possible implementation, neighborhood input can be multiple semantically similar short phrases entered successively by the player in the same interactive session. The system aggregates these into reuse groups according to the session dimension, allowing historical inputs within the same session to share the same target lyrics with the current input. For example, if a player continuously enters semantically similar phrases such as "won," "finally won," and "great" in a single creation session, the system includes all historical inputs within that session in the current neighborhood, allowing newly generated target lyrics to be directly reused by subsequent inputs in that session.

[0151] In another embodiment of this application, the neighborhood input can also be a set of inputs received within a preset time period before the current moment that belong to the same style category. This set is maintained by the system according to the time window dimension, so that inputs that meet both time period and style requirements are automatically grouped into the same reuse range. For example, the system counts all inputs expressing joy under the cute and catchy style in the past hour, regards these inputs as members of the same neighborhood, and reuses the same set of lyrics and song results.

[0152] For example, a player inputs original text expressing the joy of victory (such as "Finally cleared the level") through the graphical user interface of a terminal device and selects a fast-paced style. After receiving the input command, the system obtains the original input text and style selection parameters. If the semantic cache matching fails, the system generates target lyrics based on preset fuzzy rewriting conditions. The target lyrics carry the core emotion of the original input and are applicable to semantically similar neighboring inputs, thus completing the preparation for reuse of the intermediate product.

[0153] In step S520, a second song generation result corresponding to the target lyrics is generated.

[0154] Once the target lyrics are determined, the system triggers the subsequent song generation process based on them, converting the text-based target lyrics into a playable second song. For example, the system calls the song generation interface, submitting the target lyrics and style selection parameters together. After processing, the corresponding audio file is obtained as the second song generation result, which is then displayed to the player through a graphical user interface.

[0155] In one exemplary application of this embodiment, the player enters the original input text in the input area and selects the target style in the style selection area through the graphical user interface provided by the terminal device. After receiving the input instruction, the system obtains the original input text and style selection parameters. After semantic cache matching is determined to be unsuccessful, the system generates target lyrics according to the original input text and style selection parameters and preset conditions. The target lyrics cover the neighboring inputs that are semantically similar to the original input text, and then generates a second song generation result corresponding to the target lyrics.

[0156] An embodiment of a song generation method includes generating target lyrics according to preset conditions, such that the target lyrics cover neighboring inputs with semantic similarity to the original input text. The steps include: Generate target lyrics that retain the intent of the original input text but are not locked to the literal expression of the original input text, so that the target lyrics can be reused by multiple inputs within the same semantic neighborhood.

[0157] The method provided in this embodiment allows for the limitation of the target lyrics generation method, enabling the generated lyrics to avoid excessive fixation on literal expression while retaining the original input intent. Multiple different inputs within the same semantic neighborhood can reuse the same cached result, significantly improving the response efficiency and result consistency when players interact with the system. Because the lyrics have semantic neighborhood coverage capabilities, the caching system can support more diverse player expression methods without increasing the generation cost, enriching the adaptability of song generation content in similar semantic scenarios. At the same time, this design effectively solves the technical problem of unstable cache key values ​​caused by nondeterministic rewriting, avoids repeated calls to high-cost song generation interfaces, and reduces system resource consumption.

[0158] The above plan will be explained in detail below.

[0159] In some embodiments, the terminal can generate target lyrics that retain the intent of the original input text but are not limited to the literal expression of the original input text in the following manner: In the generation process that occurs after a cache miss, the terminal controls the level of abstraction of the output of the lyrics rewriting stage, so that the target lyrics carry the core semantic intent of the original input text, while avoiding directly embedding specific wording, specific images or proprietary descriptions of the original input text into the lyrics text. This allows the rewritten lyrics to be reused by multiple different inputs within the same semantic neighborhood.

[0160] For example, the literal expression of the original input text is the surface symbolic constraint information representing the specific word and phrase arrangement. By reducing the target lyrics' reliance on this information, the terminal preserves the deeper intent while enabling the target lyrics to cover different inputs within the same semantic neighborhood and support reuse. For example, decrypting this literal expression includes, but is not limited to, at least one of the following: not directly copying keywords from the original input text, replacing specific entity words with superordinate concept words, or rewriting specific sentence structures into general rhythmic sentence structures.

[0161] In one alternative implementation, the literal expression of the original input text is a combination of phrases containing specific emotional keywords. For example, when the original input text is a colloquial phrase expressing the joy of victory, the target lyrics do not directly copy the slang words in the phrase, but instead use a rhythmic expression common within that semantic neighborhood to carry the corresponding emotion.

[0162] In another alternative implementation, the literal expression of the original input text is a short phrase describing a comeback maneuver in a specific competitive context. For example, when the original input text records the operational details in a specific competitive scenario, the target lyrics retain the emotional intent of a comeback, but generalize the operational details into a reusable intentional description within that semantic neighborhood, so that other inputs with similar expressions can share the lyrics.

[0163] Furthermore, the above implementation methods can be implemented individually or in combination. For example, when the original input text contains both phrase combinations of specific emotional keywords and short sentences describing specific events, the terminal performs generalization processing on both phrase combinations and short sentences describing specific events simultaneously, in order to take into account the semantic coverage of both emotions and events.

[0164] For example, a semantic neighborhood is a set of similar intent input vectors formed around the semantic features of the original input text. This is coordinated with the fuzzy generation of the target lyrics, enabling a single cached entry to serve multiple different input requests falling within this set. For example, the semantic neighborhood can be defined in ways including, but not limited to, at least one of the following: statically defined by a semantic similarity threshold, formed by summarizing semantic cluster centers within style partitions, or manually configured based on distance ranges in the vector space.

[0165] In one alternative implementation, the semantic neighborhood is a vector space range within a specific style partition and surrounding the original input text that meets a similarity threshold. For example, after the original input text is vectorized, it forms the semantic neighborhood together with other cached inputs whose cosine similarity exceeds a preset threshold in this vector space, and the target lyrics are reused for these inputs accordingly.

[0166] In another alternative implementation, semantic neighborhood is a semantic equivalence class based on the player's input intent rather than keyword overlap. For example, multiple inputs with different words but all expressing the same emotion triggered by an event are grouped into the same semantic equivalence class, and inputs within the coverage of this equivalence class all trigger the reuse of the same target lyrics.

[0167] Furthermore, the above delineation methods can be used individually or in combination. For example, a terminal can delineate a semantic neighborhood in the vector space using a similarity threshold, and can also perform semantic classification using intent equivalence relations, thereby simultaneously utilizing both geometric distance and semantic category dimensions to determine the reuse scope.

[0168] For example, multiple original text requests submitted by players, whose inputs belong to the same semantic neighborhood but differ in literal expression, can be combined with a target lyrics reuse mechanism to enable a single cached lyrics response to multiple requests that are semantically similar but literally different. For example, the sources of multiple inputs include, but are not limited to, at least one of the following: similar expressions submitted by the same player at different times, similar intent requests submitted by different players, and variant requests from the same player that fine-tune previous inputs.

[0169] In one alternative implementation, multiple inputs are multiple original statements submitted by the same player in different sessions, with similar intent but different wording. For example, a player might input different colloquial phrases expressing the same joy, and these phrases are considered multiple inputs because they fall into the same semantic neighborhood and share the same song generated from fuzzy lyrics.

[0170] In another alternative implementation, multiple inputs can be requests submitted by different players for the same type of scenario event. For example, multiple players may input text describing similar interactive situations. Although their wording may differ, the system determines that these inputs belong to the same semantic neighborhood, thus reusing the same target lyrics and corresponding song.

[0171] Furthermore, the same semantic neighborhood can contain both historical variant requests from the same player and similar requests from other players. The system can trigger the reuse of the same target lyrics for these inputs from different sources.

[0172] For example, input reuse refers to a mechanism that allows different original inputs within the same semantic neighborhood to share target lyrics and corresponding song cache entries. This works in conjunction with the fuzzy generation of target lyrics, enabling a single cache entry to serve multiple semantically similar inputs to avoid duplicate generation. For example, implementations of input reuse include, but are not limited to, at least one of the following: directly returning cached song files, returning cached lyrics for front-end synchronous display, or using cached results as templates for secondary rendering.

[0173] In one alternative implementation, input reuse is manifested in directly returning the generated song asset and corresponding lyrics after a cache hit. For example, when the semantic features of subsequent inputs have a similarity to the cached vectors that reaches a threshold, the system returns the song file path and lyrics from the cached entry, thus reusing the song generation result.

[0174] In another alternative implementation, input reuse is manifested in skipping the lyrics rewriting and song generation stages and directly returning the result after a successful semantic match. For example, when subsequent input falls into an existing semantic neighborhood, the system omits the non-deterministic lyrics rewriting step and the costly song generation call, and directly retrieves the corresponding cached result to complete the response.

[0175] Furthermore, the system can directly return cached song assets and lyrics, and can also skip the lyrics rewriting and song generation stages simultaneously during reuse, thus achieving both result reuse and process optimization.

[0176] In one exemplary application of this embodiment, a player submits text describing a specific emotion and specifies a music style in the input area of ​​the graphical user interface. When the system generates target lyrics based on the original input text and style selection parameters, it retains the emotional intent the player wants to express, while replacing specific colloquial words in the player's original speech with more general rhythmic expressions. This allows the system to directly reuse the target lyrics and its associated song assets when other players submit semantically similar but worded emotional descriptions, without needing to call the language model again to rewrite the lyrics or call the song generation interface again, thus quickly returning cached results to the graphical user interface.

[0177] In one possible implementation, generating the target lyrics according to preset conditions includes the following steps: Step S610: Based on the target prompt information corresponding to the style selection parameters, the original input text is rewritten to obtain the target lyrics while preserving the intent of the original input text and reducing the degree of literal expression locking.

[0178] The method provided in this embodiment enables the system to select target prompt information corresponding to style selection parameters, thereby reducing the reliance on the original literal expression while preserving the original input text intent, obtaining target lyrics, improving the reusability of lyrics for semantically similar inputs, reducing the frequency of repeated calls in the song generation process, and solving the problem of low cache reuse rate caused by excessive binding of intermediate products to the original literal text.

[0179] Here, the target prompt information can be a rewriting guidance instruction configured for the current style selection parameters, used to limit the style tendency and content boundaries of the lyrics output. This application embodiment is not limited to the specific form of the target prompt information; for example, it can be a style descriptive word pre-configured by the system, guidance text dynamically loaded according to style parameters, or a stylized instruction template containing output format constraints.

[0180] In some embodiments, the target prompt information is pre-configured guiding text for a specific style, containing imagery and rhythmic descriptions corresponding to that style. For example, when the style selection parameter indicates a cute and catchy style, the system loads prompt information containing sweet elements and upbeat rhythms, rewriting the content about pleasant mood in the original input text into lyric fragments with childlike imagery and a light melody.

[0181] In some embodiments, the target prompt information is a rewriting instruction with structured constraints that is dynamically loaded based on style selection parameters, specifying the rhetorical devices and rhythmic formats that the lyrics should adopt. For example, when the style selection parameters indicate a rhythmic hip-hop style, the system loads prompt information containing rhyming structures and syncopation requirements, rewriting the content about the motion scene in the original input text into rap lyrics with continuous double rhymes and a strong beat.

[0182] Here, the intent of the original input text can be the core reason and emotional appeal expressed by the user's input statement, which is the semantic baseline that the rewriting process needs to maintain. This application's embodiments are not limited to this; for example, it could be describing the emotional tone of a specific event, expressing a subjective attitude towards a certain type of scenario, or conveying the core information of a specific narrative theme.

[0183] In some embodiments, the intent of the original input text is the user's core emotional appeal regarding a specific game event or life scenario. For example, when the original input text contains semantics related to a comeback, the rewriting process preserves its core of celebration and excitement, transforming it into celebratory lyrics suitable for singing.

[0184] In some embodiments, the original input text is intended to convey the sense of accomplishment and satisfaction that a player experiences after completing a specific challenge in a virtual environment. For example, when the original input text contains semantics related to overcoming difficulties, the rewriting process retains its core attitude of striving and achieving, transforming it into inspirational and positive lyrics.

[0185] Here, the degree of literal expression locking can be used to measure the dependence of the rewritten result on the vocabulary and sentence structure of the original text. Reducing the degree of literal expression locking can be achieved by avoiding direct quotations of keywords from the original input, using synonyms to change the expression, or reorganizing the sentence structure while retaining the core meaning.

[0186] In some embodiments, reducing literal expression locking manifests as avoiding the direct reuse of specific keywords from the original input text. For example, when the original input text contains a description of the action of running, the rewriting process uses alternative words such as galloping or running fast, allowing other inputs expressing rapid movement to also establish a semantic association with the lyrics.

[0187] In some embodiments, reducing literal expression lock-in involves reorganizing the sentence structure of the original input text. For example, when the original input text uses a subject-verb-object structure to describe a specific event, the rewriting process adjusts it to a more general narrative and replaces specific nouns with generic terms, making the lyrics applicable to various other inputs describing similar events.

[0188] Here, rewriting can be a process of semantically preserving text re-creation based on stylistic prompts of the original input. The embodiments of this application are not limited to specific implementations of the rewriting process; for example, it can be structured rewriting based on rule templates, generative rewriting by calling a language model, or composite rewriting that combines multiple strategies.

[0189] In some embodiments, the rewriting process involves invoking a language model to perform an end-to-end generative rewriting of the original input text based on the target prompt information. For example, the system submits the user-inputted description of a victory moment along with cute-style prompts to the language model to obtain lyrics output with an energetic style that does not directly copy the original words.

[0190] In some embodiments, the rewriting process is a structured rewriting based on preset sentiment tags and style lexicons. The system first identifies the original semantics and then calls on the corresponding style's vocabulary resources for reconstruction. For example, after identifying the sentiment tag about hard work in the original input text, the system selects matching words from the inspirational style lexicon and reorganizes them into lyrics that conform to the melody structure.

[0191] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0192] Players submit original text about a weekend trip to the beach in the input area of ​​the graphical user interface, selecting an energetic, eccentric style. Based on the target prompts corresponding to this style, the system rewrites the original text while preserving the relaxed and casual intention and reducing the literal targeting of specific location terms, generating target lyrics with an energetic style that do not directly copy the original words.

[0193] In one possible implementation, the aforementioned target prompt information is a dedicated prompt information corresponding to the style selection parameters, with different style selection parameters corresponding to different dedicated prompt information. The method provided in this embodiment enables different style selection parameters to be configured with different dedicated prompt information, introducing style-bound directional guidance during the lyrics rewriting stage. This ensures that the language model generates lyrics according to a specific style paradigm to improve the accuracy and richness of style expression, and also allows the stylized, ambiguous lyrics to maintain semantic alignment with similar inputs during semantic caching reuse. This improves the interactive experience and the rationality of caching reuse, and avoids misuse of computer cache resources and invalid calls to the song generation interface due to style confusion.

[0194] In one possible implementation, when rewriting the original input text, a preset language model is invoked, and the rewriting is performed based on the target prompt information within a preset temperature parameter range.

[0195] The method provided in this embodiment adds temperature parameter constraints when rewriting by calling the language model, which not only preserves the user's core expressive intent, but also avoids the output being overly locked to the original literal meaning, thereby improving the lyrics acquisition experience, enhancing the expressive richness of music generation content, and reducing the problem of difficulty in reusing cached key-value pairs due to excessive generation uncertainty.

[0196] Specifically, the language model, acting as the rewriting execution entity, has its inference randomness constrained within a preset temperature parameter range. Guided by target prompts, the model performs semantic transformation on the original input text, outputting target lyrics that retain the original intent but deviate from the original literal expression.

[0197] The pre-defined language model refers to a generative neural network used for text semantic rewriting. Optionally, this model can be an open-source large language model, or a conditional generative network based on a hybrid expert architecture, a text style transfer model optimized based on adversarial training, or a semantically preserving sequence generation model based on knowledge graph enhancement.

[0198] In one exemplary application of this embodiment, after a user enters "I miss you, the moonlight is so beautiful tonight" in the input area of ​​the graphical user interface and triggers a song generation request, the system sets the sampling temperature to 0.7 and calls a preset language model to rewrite the lyrics based on the target prompt information, resulting in "Moonlight spills onto the windowsill, longing overflows the sea of ​​my heart." This target lyric retains the intention of missing someone far away, but reduces the dependence on the original literal meaning, thus providing a reusable lyric basis for semantically similar neighboring inputs such as "I miss you so much tonight" and "longing under the moonlight."

[0199] After generating target lyrics based on the original input text and style selection parameters, the terminal sends the target lyrics and style selection parameters to the song generation interface to convert them into a playable song, and receives the second song generation result returned by the interface. Through the method provided in this embodiment, the terminal does not need to deploy a complex song synthesis model locally; it can obtain song data matching the target lyrics and selected style from the server, thereby reducing the terminal's local computational load and resource consumption. Simultaneously, users can quickly obtain stylized song feedback in the graphical user interface, enriching the types of music content that can be presented.

[0200] During the transmission process, the terminal encapsulates the target lyrics and style selection parameters into a generation request and submits it to the song generation interface. This interface is the endpoint exposed by the server to receive lyrics and style parameters and return the corresponding song data. For example, the terminal can send a structured request message containing the target lyrics and style identifiers (such as "rock" or "pop") to the cloud-based music generation service via the HTTP protocol.

[0201] After the server performs song synthesis based on the received parameters, it sends the second song generation result back to the terminal. This result typically includes song audio data that matches the target lyrics and selected style, such as an audio file address or a direct audio stream. Upon receiving this result, the terminal can present it to the user in a graphical user interface and support playback.

[0202] In an exemplary application of this embodiment, the terminal has obtained the blurred target lyrics and the style selection parameters selected by the player in the graphical user interface. The target lyrics and style selection parameters are sent to the song generation interface. After the interface server completes the song synthesis according to the parameters, the terminal receives the returned second song generation result and presents the second song generation result in the graphical user interface.

[0203] After generating the target lyrics, considering that song generation interfaces usually have specific requirements for input format and often adopt asynchronous task mode, the terminal can preprocess the lyrics before submitting them, and track the generation progress through a polling mechanism and download the results in a timely manner after completion.

[0204] Specifically, the steps of sending the target lyrics and the style selection parameters to the song generation interface include: Step S710: Remove paragraph markers from the target lyrics to obtain clean lyrics.

[0205] Step S720: Submit the clean lyrics and style selection parameters to the song generation interface.

[0206] The steps for receiving the second song generation result returned by the song generation interface include: Step S730: Poll the task status of the song generation interface; Step S740: If the task is completed, download the second song generation result to the local machine.

[0207] The method provided in this implementation ensures that before submitting the target lyrics to the song generation interface, paragraph mark removal is performed to remove formatting marks from the lyrics, thereby ensuring that the lyrics text received by the interface conforms to the parsing standard and avoiding parsing anomalies caused by format redundancy. Simultaneously, a polling mechanism continuously tracks the asynchronous generation progress on the interface side, and the results are promptly downloaded to local storage upon completion of the task. This allows users to stay informed about the processing status throughout the generation process and quickly obtain locally accessible song files after generation, thus improving the user experience. In song generation applications, the standardized lyrics submission process combined with a localized result storage mechanism enriches the interactive forms and application scenarios of song generation. In the computer field, it effectively solves the problems of insufficient awareness of asynchronous task status, delays in obtaining generation results, and incompatibility of interface input formats, ensuring the robust execution of the song generation chain.

[0208] The following provides a further explanation of the specific implementation of each step.

[0209] Many song generation interfaces require the input text to be a continuous single-line string and do not accept rich text or segmented formatting. Therefore, in step S710, the terminal filters out formatting marks such as line breaks, leading spaces, and blank lines from the target lyrics, while retaining semantic pause marks such as commas and periods, resulting in clean lyrics. Of course, in practical applications, depending on the interface specification, the removal of paragraph marks can also be achieved by removing invisible format control characters, using unified character encoding, or escaping special characters, etc. This application does not specifically limit this approach.

[0210] In step S720, the terminal encapsulates the obtained clean lyrics and the user-selected style parameters into a request data packet, and sends it to the song generation interface via the Hypertext Transfer Protocol to trigger an asynchronous song generation task. For example, the lyrics text after removing line breaks and the "cute and catchy" style tag are submitted to the interface together.

[0211] Because song generation is time-consuming, the interface typically processes submitted requests asynchronously. Therefore, in step S730, the terminal sends status query requests to the interface at preset time intervals, polling the task status until the task is confirmed to be complete. For example, the system can send a standard query message carrying a task identifier every 3 seconds, parsing the status field in the response to determine the current generation progress. Furthermore, the polling strategy can be dynamically adjusted according to the interface load: when the response indicates the task is in a queue, the query interval is extended to 10 seconds to reduce server pressure; when the response indicates the task is being generated, the interval is shortened to 2 seconds, thereby reducing system overhead while ensuring timely status awareness. This application does not specifically limit the specific polling strategy.

[0212] It should be noted that the task status returned by the interface can be either a discrete enumeration value representing the task lifecycle, such as "pending", "processing", or "completed"; or it can also contain structured information such as generation stage identifier and real-time progress percentage, which can be used by the front end to render a progress indicator bar or display in multiple dimensions.

[0213] In step S740, when the polling result indicates that the task is complete, the terminal triggers the download process and saves the second song generation result locally. For example, when the interface returns a Hypertext Transfer Protocol status code of 200 and the response body carries the Network Uniform Resource Locator (URL) of the song file, the system confirms that the song file is ready and then opens the download channel to pull the resource from the server to the terminal. The local storage location can be either the terminal's built-in public music directory so that the player component can directly read and decode it, or a private isolated cache directory bound to the currently logged-in account, which uses file system permission control to avoid data mixing and privacy leakage in a multi-user environment. Of course, in practical applications, the specific path and form of local storage can be flexibly selected according to the terminal system architecture, and this application does not specifically limit this.

[0214] In an exemplary application of this embodiment, the user inputs original text and selects a cute and catchy style on the front-end interface. After the system misses the cache, it generates target lyrics using a language model. Subsequently, the system removes paragraph marks from the lyrics, removing line breaks to obtain continuous text. This continuous text, along with the cute and catchy style parameters, is submitted to the song generation interface. After the interface receives the submission, it enters the asynchronous generation stage. The system polls the task status returned by the interface at three-second intervals. When the status field changes to "completed," the system immediately downloads the generated second song to the local music folder of the terminal device and displays playback controls and a lyrics display area in the graphical user interface for the user to listen to.

[0215] In some embodiments, to reduce repeated interactions caused by missing parameters, the terminal encapsulates the clean lyrics, style selection parameters, model parameters, and title parameters into a complete request body before sending it when calling the song generation interface. The unformatted lyrics (after paragraph removal) serve as prompts for semantic input; the style selection parameters are mapped to tags to define the synthesis approach; the model parameters specify the technical configuration of the generation process; and the title parameters serve for task indexing and result archiving.

[0216] This application provides a flowchart of a song generation method according to an exemplary embodiment. The step of submitting the clean lyrics and the style selection parameters to the song generation interface includes: submitting the clean lyrics as prompt words, the style selection parameters as tags, and the model parameters and title parameters together to the song generation interface.

[0217] The method provided in this implementation enables the song generation interface to accurately understand the generation intent based on complete parameter configuration, reducing repeated submissions and corrections due to missing parameters, thereby improving the user's interactive experience in the music creation process. Simultaneously, the introduction of model parameters and title parameters expands the adjustable dimensions of song generation, allowing the same combination of lyrics and style to generate more personalized audio performances, effectively enhancing the richness of music content. Furthermore, integrating multiple types of parameters into a standardized request optimizes the data interaction structure between the front-end and the song generation interface, reducing the interface call failure rate and improving the overall stability and reliability of the system.

[0218] Next, we will explain the specific role of each parameter in the request.

[0219] In practical applications, the terminal first removes paragraph marks from the original lyrics, obtaining continuous, unformatted text, which is then directly set as the prompt word. This prompt word conveys the core semantics and emotional tone of the song to the interface. For example, after the user-inputted original lyrics are cleaned and submitted as continuous text, the interface identifies emotional keywords in the lyrics and matches them with corresponding singing styles.

[0220] Correspondingly, the style selection parameters are encoded as tags and sent with the request, serving as the basis for style routing in the API. For example, if a user selects the "cute and catchy" style on the front end, the terminal will map the style to the corresponding tag and submit it. After the API recognizes this, it will call the synthesis template of upbeat rhythm and sweet tone. If the user switches to "rhythmic hip-hop", the tag will trigger the API to switch to the hip-hop beat and rap tone template, generating a segment with a strong rhythm.

[0221] Next, the terminal supplements the request body with model parameters and title parameters. Model parameters are used to declare the target generation model instance or accompaniment arrangement rules. For example, setting the model parameter to a specified neural network version will allow the interface to schedule that version of the model for synthesis, ensuring output stability and consistency. Alternatively, the model parameter can be configured as an electronic synthesizer lead identifier; after parsing, the interface will use electronic timbres to arrange the accompaniment, giving the generated audio a digital atmosphere at the orchestration level. The title parameter serves as a task management identifier. It can be manually set by the user—for example, naming the song "Rainy Playground"—and the interface will record this title for indexing in the task queue; or it can be automatically extracted by the system based on the semantics of the lyrics, allowing for quick location in the history.

[0222] As shown in the image [instructing the user to enter a serial number] In one exemplary application of this embodiment, after the player completes the segment removal process of the target lyrics and selects a cute and catchy style on the front-end interface, the terminal encapsulates the cleaned lyrics text as prompt words, the selected style as a tag, along with the specified multimodal model version parameters and the custom song title parameters into a structured request body, and submits it to the song generation interface in one go. After receiving the request, the interface parses each field and starts an asynchronous song synthesis task. After the task is completed, the generated song file is returned to the terminal for display.

[0223] After generating the second song corresponding to the target lyrics, this generated result can be written to a semantic cache to expand the reusable cache entries. In one possible implementation, the semantic features corresponding to the original input text, the target lyrics, and the second song generation result are written to the semantic cache as a single cached data entry. Using the method provided in this embodiment, after generating the second song, the system writes the semantic features corresponding to the original input text, the target lyrics, and the second song generation result as a whole into the semantic cache, so that they can be directly reused when triggered by subsequent semantically similar inputs, reducing the resource consumption of repeatedly calling the song generation interface.

[0224] Specifically, the system obtains the semantic features of the original input text after vectorization, and writes them together with the target lyrics and the second song generation result as a complete cache data into the semantic cache.

[0225] Here, cached data refers to the record entries in the semantic cache that associate and store semantic indexes with generated artifacts. Cached data can be stored in different databases by style partitioning, or it can be appended with timestamps and hit counts to support cache management, or it can be persistently stored using a key-value pair structure. Furthermore, the embodiments of this application are not limited to the specific organization of the cached data; for example, it can be an atomic pair structure, a key-value pair structure, or style-partitioned isolation, or multiple methods can be used simultaneously. The system can be flexibly configured according to actual needs.

[0226] Optionally, the cached data consists of atomic pairs containing semantic feature vectors, lyrics text, and song file paths. These three elements are written as a whole to the cache space of the corresponding style partition to ensure that all content is retrieved simultaneously upon a hit, avoiding separation of the song and lyrics. For example, the vector corresponding to the player's input "Today's comeback was so awesome", the rewritten lyrics "The moment of comeback was so happy", and the local song file path " / cache / song123.mp3" are packaged into a single cached data entry and written to the "Cute and Catchy" style partition so that similar inputs can be directly reused in the future.

[0227] Optionally, cached data is automatically built after each miss is generated. For example, if a player selects the "Rhythmic Hip Hop" style and enters "Turnaround!", the system will generate the lyrics "Turnaround rhythm can't stop" and the corresponding song, and then store the input vector, the lyrics, and the song file as cached data in the style partition. When a subsequent player enters "Turnaround is so happy" with similar meaning, the entry can be reused directly.

[0228] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0229] When the terminal device receives the player's input of "I got lucky with my gacha pull" and the selected "cute and catchy" style via the graphical user interface, if the cache for the corresponding style is not found, it generates the target lyrics and the second song in sequence. Then, the semantic features obtained by vectorizing the original input text, the target lyrics "Good luck with gacha pulls," and the local file path of the second song are used as cache data and written into the style section of the semantic cache. When a player subsequently inputs "My gacha pulls were really good today" and selects the same style, the system directly hits the cache data and returns the song and lyrics.

[0230] In this embodiment, after the terminal generates a second song corresponding to the target lyrics, it can write the semantic features corresponding to the original input text, the target lyrics, and the second song generation result into the semantic cache in the following way: storing the three as an inseparable whole.

[0231] For example, the aforementioned indivisible whole refers to an atomic storage structure that binds the semantic index key, lyrics text, and song output into a single cache entry. This atomic storage structure uses semantic features as the basis for hit retrieval, enabling multiple inputs within the same semantic neighborhood to fully reuse the cached generated results. In actual storage form, this atomic storage structure can also be implemented, but is not limited to, at least one of the following: serializing the three into binary data blocks and writing them to distributed cache nodes; using semantic features, lyrics, and song path as associated fields in the same data table for transactional writing; packaging the three into a compressed file and storing it in an object storage system, using the hash value of the semantic features as the object identifier.

[0232] Furthermore, in one optional implementation, the indivisible whole consists of a logically related semantic index and a multimedia resource set within the semantic cache. These three elements are mapped and bound together in the cache using unified identification information. During a search, a single identifier allows for the retrieval of all associated content at once, avoiding incomplete data retrieval due to scattered storage. For example, when a user inputs text expressing a celebratory intent through a graphical user interface, the system assigns a unique number to the semantic vector of that text, along with the rewritten celebratory lyrics and the corresponding song file, and stores them together in the cache partition. Subsequent inputs with similar semantics directly return the complete song and lyrics resource set corresponding to that number.

[0233] In another alternative implementation, the indivisible whole is a structured record with a fixed field format. Semantic features, lyrics, and song data are arranged in a preset order within the same record. The system can obtain complete and consistent information by parsing the data in the order of the fields during reading. For example, after a user submits text expressing a comeback theme through the input area, the system generates a structured record containing the text vector, inspirational lyrics, and the corresponding song path, and stores it in the local cache. When similar inputs are found later, the system directly parses and outputs the song and lyrics from this record without performing additional retrieval and matching.

[0234] It should be noted that the above-mentioned storage formats can be used individually or in combination depending on the actual deployment environment, and this application does not impose any restrictions on this.

[0235] In one specific application, after generating the second song, the terminal device encapsulates the semantic features of the original input text, the target lyrics, and the generated second song into a single cache record, storing it as an indivisible whole within the corresponding style partition of the semantic cache. Subsequent user input with similar semantics that hits this cache can directly extract and return the complete lyrics and song from this single cache record.

[0236] The method provided in this implementation stores the semantic features of the original input text, the target lyrics, and the generated second song as an indivisible whole. Each cache entry carries the complete mapping between the semantic index and the generated result. Subsequent hits allow for direct extraction of the bound song and lyrics, returning them to the graphical user interface. This enables players to quickly obtain stylistically consistent and data-complete songs without waiting for regeneration when inputting semantically similar content, significantly improving the continuity and responsiveness of the interactive experience. Simultaneously, this atomic storage mechanism allows multiple user inputs within the same semantic neighborhood to stably reuse the same set of generated content. The system can continuously accumulate song assets of different themes for reuse in multiple scenarios, thereby enriching the breadth and diversity of in-game music content. Furthermore, this holistic storage method eliminates the burden of maintaining data consistency caused by multiple queries under distributed storage, effectively avoiding cache anomalies or matching errors that may occur due to the separation of index and content. This significantly reduces the complexity of storage management and system overhead while ensuring cache hit rate.

[0237] In one possible implementation, when the semantic features corresponding to the original input text, the target lyrics, and the second song generation result are written as cached data into the semantic cache, these three are stored as atomic pairs in the local storage path.

[0238] The method provided in this implementation firmly binds semantic features, lyrics, and song generation results to the local storage path, preventing missing fields or mapping errors during the reading and writing of cached data. This ensures that songs and lyrics can be synchronously and completely accessed, meeting the requirements for audiovisual consistency; it also supports the long-term accumulation of song assets corresponding to different semantic inputs, expanding the reusable content library; and it solves the storage reliability problem of easily mismatched cached unstructured data.

[0239] The above plan will be explained in detail below.

[0240] In step S1810, the semantic features corresponding to the original input text, the target lyrics, and the second song generation result are stored as atomic pairs in the local storage path.

[0241] Specifically, when a cache miss occurs, the terminal device obtains the semantic features of the original input text after vectorization, as well as the rewritten target lyrics and the second song generation result returned by the song generation interface. These three elements are then coupled and stored locally: semantic features serve as the retrieval basis, lyrics as the semantic context, and the song file as the output asset, forming an indivisible storage unit to ensure the integrity and consistency of the cached content.

[0242] The local storage path is an identifier used to locate the persistent storage location of the song generation results on the terminal device. Based on this identifier, a path-based mapping is established between the song file, semantic features, and lyrics, achieving consistent addressing of cached assets. For example, this path can be a content addressing path generated based on a hash value, a node path in a distributed file system, or a logical bucket path in an object storage service.

[0243] Optionally, the local storage path is a local resource directory address that the front-end playback control can directly parse. After the song file is written to this address, it is bound and archived with the semantic vector and lyrics text. When the cache query is hit, the audio stream can be directly loaded from this address, and the song resource can be retrieved seamlessly in the graphical user interface. For example, after a player enters a statement to celebrate completing a level and selects the "electronic music" style, the system generates a song and stores the audio file in the terminal's local audio cache directory (e.g., / sdcard / game / audio_cache / ). This directory path is written as a cache entry along with the semantic vector and lyrics; when similar semantic inputs are hit subsequently, the front-end directly retrieves the audio from this path for playback.

[0244] Optionally, the local storage path can also be a unique identifier path generated based on a content addressing mechanism. Song files are mapped to fixed paths according to their content digests, and a correspondence is established between these paths and semantic features and lyrics, avoiding file drift or duplicate storage and improving the utilization efficiency of terminal storage space. For example, if two players in the same semantic neighborhood trigger song generation one after another, and the generated results are both a1b2c3… after MD5 digest calculation, the local content addressing path of the existing song (such as / ipfs / QmXyz…) is reused in a new cache entry without repeated disk writes, thereby saving terminal storage space and maintaining cache consistency.

[0245] In actual deployment, the system can use the local directory address that can be resolved by the front end as the basic storage path, or it can combine the content addressing mechanism to reuse the path of the same song file, or use different path management methods for different types of song assets, so as to adapt to the diverse storage environment and access needs of the terminal.

[0246] In this context, atomic pairs represent the state constraints of cached data existing as the smallest indivisible unit at the logical level. Based on this constraint, semantic features, lyrics, and song generation results are encapsulated as a unified whole and written to the cache, avoiding data mismatch caused by field splitting. For example, this atomic pair can be an atomic commit of an entire row in a database transaction, a nested encapsulation structure in a large binary object, or an indivisible evidence storage unit in a blockchain.

[0247] Optionally, an atomic pair is a complete data encapsulation that is followed by both the front-end display and the back-end cache. The semantic vector, lyrics text, and song file path are packaged into a single entry, and all three are called synchronously during cache reads to prevent only the song from being returned while the lyrics are missing. For example, after a cache hit, the system synchronously loads the lyrics text from the entry into the lyrics display area, and simultaneously retrieves the audio file based on the path for playback, ensuring that the user can see the corresponding lyrics on the interface while listening to the song, maintaining a consistent audiovisual experience.

[0248] Optionally, atomic pairs can also be cache write units with transactional consistency. Semantic features, lyrics, and song generation results are persisted in a single write operation, ensuring that no incomplete data is generated due to interruption during cache updates. For example, when performing song generation and cache backfilling after a cache miss, the system waits until vector calculation, lyrics rewriting, song generation, and local disk writing are all completed before writing all three as atomic entries to the cache partition at once; if an exception occurs during the write process, the entire process is rolled back to avoid dirty reads of the cache caused by semantic vectors being written but song files being missing.

[0249] In practical implementation, the above two atomic pair constraints can be used individually or simultaneously. For example, the system packages the three into a data encapsulation body and uses a transaction mechanism to ensure atomicity during writing, in order to adapt to the data reliability requirements of different terminal environments.

[0250] In this context, associative storage is a write organization method that establishes fixed mapping relationships between multiple fields in persistent media. Semantic features, lyrics, and song files maintain their binding relationships during reading, supporting consistent return and reuse after cache hits. For example, this associative storage can be a foreign key related table structure in a relational database, a nested object model in a document database, or an edge node related network in a graph database.

[0251] Optionally, the associated storage adopts an archiving method that binds semantic retrieval keys with the visual representation of the displayed content. A cache file is established with a one-to-one correspondence between the player's original semantic input and the final audible and viewable song output, allowing subsequent similar inputs to directly retrieve the same musical experience. For example, if a player inputs "Congratulations on clearing the level, so happy!" and selects the "rock" style, the system associates the semantic vector of that input, the rewritten lyrics, and the path to the generated song file and writes them into the "rock" partition. When subsequent similar semantic expressions (such as "Successfully cleared the level, in a great mood") are found in the same partition, the lyrics and song are reused, maintaining a consistent presentation of style and semantics.

[0252] Optionally, the associated storage can also be a domain-specific binding mechanism isolated by style partitions. Semantic features, lyrics, and song generation results are mapped and archived only within the current style partition, avoiding misuse of songs that do not match the requested style due to cross-style data mixing. For example, the original input text "festival celebration" generates a cached entry under the first style (such as "Chinese style"), and its semantic vector, lyrics, and song path are only associated and stored within that style partition. When the player switches to the second style (such as "jazz") and inputs similar semantics, the system independently creates a new associated entry within the "jazz" partition, preventing the misassignment of "Chinese style" songs to "jazz" style requests.

[0253] In practical applications, the above archiving methods can be used individually or in combination. For example, while establishing semantic keys and binding them to song content within the same partition, the system can also associate and archive lyrics with audio across display dimensions to balance cache hit accuracy and data organization flexibility.

[0254] Taking a practical example, the terminal device receives input commands from the player for the input and style selection areas via the graphical user interface, obtaining the original input text and style selection parameters. After semantic matching determines that the cache has not been hit, the system calls the language model to rewrite the original input text into target lyrics, and sends the target lyrics and style selection parameters to the song generation interface, receiving the returned second song generation result. Subsequently, the semantic features corresponding to the original input text are extracted, and the semantic features, target lyrics, and second song generation result are stored as atomic pairs in the terminal's local storage path, forming a complete cache entry containing a semantic index, lyrics context, and audio asset path. Subsequent inputs with similar semantics within the same style partition can hit this entry, directly returning consistent lyrics and songs, thereby improving the reuse efficiency of song generation results and reducing the frequency of calls to high-cost interfaces.

[0255] As shown in the image [instructing the user to enter a serial number] In one exemplary application of this embodiment, a player enters text describing their feelings of victory in battle (e.g., "I defeated the final boss today, I'm so excited!") in the input area through the graphical user interface of their terminal device, and selects the "Epic Orchestra" style. After performing semantic matching within the current style partition, the system determines that the cache has not been hit. Therefore, it rewrites the original input text into the target lyrics and generates a corresponding second song. Subsequently, the semantic features of the original input text, the target lyrics, and the second song are stored as atomic pairs in the local storage path. When another player subsequently enters a similar victory description (e.g., "Finally cleared the game, so exciting!") and selects the same style, the system hits the aforementioned cache entry within that style partition, directly returning the associated lyrics and song file path. The front-end loads the audio based on this path and synchronously displays the lyrics.

[0256] In one possible implementation, when writing the semantic features corresponding to the original input text, the target lyrics, and the second song generation result into the semantic cache, the semantic features can also be written as the starting point of a new neighborhood. If subsequent inputs hit the semantic cache, the subsequent inputs are assigned to this new neighborhood, so that the neighborhood of the semantic cache can be dynamically expanded as cache entries increase.

[0257] The method provided in this embodiment generates a new song result when the original input text fails to hit the cache. The system uses the semantic features of the original input as the starting point of a new neighborhood for writing, and then assigns it to the neighborhood when subsequent similar semantic inputs are hit, thereby achieving dynamic expansion. As a result, players are more likely to hit the cache and quickly obtain the song return, reducing repeated waiting time. At the same time, the same song generation result can cover a richer range of semantically similar expressions, meeting the needs of similar music in different game scenarios. Furthermore, the semantic cache does not need to be pre-divided into fixed categories and can adaptively form semantic clusters as data accumulates, reducing cache maintenance costs and improving the reuse efficiency of storage resources.

[0258] Referring to the figure [instructing the user to fill in the serial number], steps S2110 and S2120 are described below.

[0259] In step S2110, the semantic features corresponding to the original input text are written into the semantic cache as the starting point of the new neighborhood.

[0260] Specifically, when the original input text does not find a match in the semantic cache, the semantic feature is marked as the starting node of a new semantic cluster when the corresponding semantic feature, target lyrics, and second song generation result are written to the cache. The starting point of the new neighborhood can be a baseline feature vector in the semantic cache used to anchor a class of similar semantic inputs. This application's embodiments are not limited to the specific form of the starting point; for example, it can be a multi-dimensional semantic vector after vectorization, a standard semantic index after normalization and dimensionality reduction, or a composite feature identifier with style labels, etc.

[0261] In one possible implementation, the starting point of the new neighborhood can be a combination of semantic features carrying a style partition identifier. The system binds the original speech vector to the style tag, ensuring that the starting point simultaneously includes both semantic benchmarks and style constraints. For example, within the "cute and catchy" style partition, the system binds the player's original speech vector to that style tag and writes it as the starting point of the new neighborhood, ensuring that subsequent expansion and reuse of this neighborhood are always limited to the current partition, avoiding semantic interference and misuse between different music styles.

[0262] For another example, after a player inputs a first text describing a victory scene of a game character and selects a hip-hop rhythm style, the system fails to hit a matching result in the semantic cache of the corresponding style partition, then generates the corresponding target lyrics and a second song generation result, and writes the semantic feature obtained by vectorizing the first text into the semantic cache of the style partition as the starting point of a new neighborhood, so as to establish a new semantic cluster anchored by the semantics of the victory scene.

[0263] In step S2120, in the case that a subsequent input hits the semantic cache, the subsequent input is classified into the new neighborhood, so that the neighborhood of the semantic cache dynamically expands as cache entries increase.

[0264] Specifically, when a new player input hits an existing entry in the text cache after semantic matching, the system associates the semantic feature corresponding to the new input with the existing new neighborhood, so that the coverage of the neighborhood adaptively expands with the accumulation of cache entries. The subsequent input may be a player request text that is later than the starting point input in time sequence and has a semantic similarity reaching a threshold. The embodiments of the present application are not limited to the specific source of the subsequent input, for example, it may be similar emotion text input by the same player after different matches, semantically equivalent text describing the same type of event by different players, or intent-consistent text after colloquial variants, etc.

[0265] Here, the neighborhood may be a logical classification area formed in the same style partition with semantic similarity as the link in the semantic cache. The embodiments of the present application are not limited to the boundary division manner of the neighborhood, for example, it may be a static range divided based on a fixed similarity threshold, or a dynamic range whose boundary adaptively changes with the accumulation of hit inputs.

[0266] In a possible implementation, the subsequent input may be a new player's original words in the same style partition whose cosine similarity with the starting point vector exceeds a threshold. After the system confirms the semantic similarity through vectorization comparison, it classifies the subsequent input into the new neighborhood corresponding to the starting point to reuse the cached song and lyric resources. For example, when a player inputs "so happy to turn the tables" under the cute and catchy style and the similarity with the starting point vector in the cache reaches 0.82, the system determines that the input is classified into the corresponding new neighborhood, and directly returns the songs and lyrics already cached in the neighborhood.

[0267] In a possible implementation, the new neighborhood may be a semantic cluster in a single style partition that takes the starting point vector as the centroid and measures the boundary through cosine similarity. The system incorporates hit inputs exceeding the threshold into the same set to form a logical area that shares the same copy of lyric and song resources internally. For example, in the cute and catchy partition, with the vector of a specific player's input as the center, all hit inputs with a similarity exceeding 0.7 jointly form a new neighborhood, and when any input in the neighborhood is matched, the same copy of cached song and lyrics is directly returned.

[0268] Optionally, the new neighborhood may also be a dynamic data structure in the cache database that associates a starting point with a plurality of hit nodes in the form of a linked list. The system attaches a new hit input under the starting point node through an index relationship to form a hierarchical semantic sharing organization; it may also be an atomic pair extension group that simultaneously contains the starting point vector, the corresponding lyrics, and the song path.

[0269] In a possible implementation, the specific process of dynamic extension may further include: the system automatically adjusts the similarity threshold according to the hit frequency to loosen or tighten the neighborhood boundary. The threshold is tightened during high-frequency hits to ensure reuse quality, and the threshold is loosened during low-frequency hits to increase the hit probability. For example, when a certain neighborhood is hit more than a hundred times within one day, the system fine-tunes the matching threshold of the neighborhood from 0.7 to 0.75 to make the extension more targeted.

[0270] In the following, an exemplary application of the embodiments of the present application in a practical application scenario will be described.

[0271] As shown in Figure [instruct user to fill in the serial number], a player inputs "So happy that I made a comeback" under the cute and catchy style section. After calculating its vector, the system compares it with the cached semantic feature starting with "It's so cool that I made a comeback today", and the similarity reaches 0.82 to hit the cache. The system classifies the subsequent input into the new neighborhood corresponding to the starting point, so that the coverage of the neighborhood is extended to the semantic region containing "So happy that I made a comeback", thereby reusing the cached songs and lyrics in the neighborhood for return, without the need to call the high-cost links of lyric rewriting and song generation again. As more players successively input similar comeback-related texts and hit, the neighborhood gradually expands into a generalized semantic region covering "reversal / counter-kill / comeback", and subsequent similar inputs will fall into the expanded region for direct reuse.

[0272] In a possible implementation, the above displaying the first song generation result or the second song generation result through the graphical user interface may include: Step S810: Display a song playback control and a lyric display area through the graphical user interface; Step S820: In response to receiving a trigger operation for the song playback control, play the first song generation result or the second song generation result, and synchronously display the corresponding lyrics in the lyric display area.

[0273] The method provided in this embodiment enables the terminal device to simultaneously provide song playback controls and lyrics display area through a graphical user interface during the song generation result display stage. It also responds to user-triggered operations to achieve synchronized audio playback and lyrics presentation, thereby enhancing the interactive experience and allowing users to complete listening and reading within the same interface. This enriches the multimedia presentation and content hierarchy of song generation applications. Furthermore, by integrating playback control and lyrics display into the graphical user interface, it solves the problem of synchronized audiovisual output and human-computer interaction of the generated results on the terminal side, reducing the operational costs for users after obtaining the generated content.

[0274] The above plan will be explained in detail below.

[0275] In step S810, after obtaining the first song generation result or the second song generation result, the terminal device simultaneously presents interactive components for controlling audio playback and a visual area for displaying text content in the graphical user interface, so that the user can learn about the song content and perform playback control based on the same interface.

[0276] In step S820, upon receiving a trigger operation for the song playback control, the first song generation result or the second song generation result is played, and the corresponding lyrics are displayed synchronously in the lyrics display area.

[0277] When a user interacts with the song playback control and generates an operation command, the terminal device calls the audio playback module to render the first song generation result or the second song generation result, and drives the lyrics display area to update and highlight the currently sung text content according to the playback timeline, so as to achieve synchronized audio-visual output.

[0278] The triggering operation refers to the human-computer interaction command that the user performs on the playback control to activate the audio decoding process, such as a click operation, a swipe operation, or a long press operation.

[0279] The corresponding lyrics refer to a set of texts that match the semantic content of the currently playing song, such as monolingual lyrics, bilingual text, or formatted text containing segmentation markers.

[0280] In one exemplary application, a user inputs raw text into the graphical user interface, which is then matched against a cache to obtain a first song generation result. At this point, a song playback control with an embedded circular play icon appears at the bottom of the result page, while a lyrics display area for text display appears in the center of the interface. The user triggers the song playback control by clicking, and the terminal device then plays the first song generation result, highlighting the currently sung sentence in the lyrics display area so that the user can view the corresponding text content in real time while listening to the generated song. Optionally, the lyrics display area can also highlight the text content corresponding to the current melody sentence by sentence according to the playback time until the entire song has finished playing.

[0281] After displaying the first or second song generation result through the graphical user interface, the corresponding song file and lyrics can be obtained, assembled to generate a music video, and then presented. Specifically, this includes the following steps: Step S910: Obtain the first song generation result or the second song generation result and lyrics; Step S920: Based on the first song generation result or the second song generation result and lyrics, assemble and generate a music video; Step S930: Display the music video through the graphical user interface.

[0282] The method provided in this embodiment allows the terminal device to further integrate the audio data with the corresponding lyrics into a music video after the song generation result is returned, and present it in the graphical user interface. This enriches the content display dimension in a combination of audio and video, while reusing existing song generation results and lyrics resources, avoiding independent video rendering computation overhead, and reducing the consumption of media processing resources on the terminal side.

[0283] In step S1910, specifically, after the terminal device displays the first song generation result or the second song generation result in the graphical user interface, it reads the currently returned song file data from local storage or memory and extracts the lyrics text content that matches the song.

[0284] The lyrics are the text material corresponding to the song's audio. The lyrics can be provided as complete paragraphs or broken into lines, and may also include timestamps to support word-by-word synchronization.

[0285] In one possible implementation, the lyrics can be text content containing line-by-line timestamps. For example, the terminal device parses several lines of lyrics corresponding to song segments from cached entries or generated responses, with each line of lyrics accompanied by start and end timestamps, so that they can be displayed according to the timeline during subsequent assembly.

[0286] Optionally, the lyrics can be text containing line breaks and sentence tags. For example, after obtaining the second song generation result, the terminal device reads the stored five lines of lyrics, each line of lyrics being identified as either a verse or a chorus section. During assembly, the corresponding lines of lyrics are presented sequentially according to the song's section switching time points.

[0287] The embodiments of this application are not limited to the specific organization of lyrics. For example, they can be sentence-by-sentence text with timestamps, lyrics text with sentence tags, or a combination of timestamps and sentence tags.

[0288] In step S1920, specifically, the terminal device synchronously merges the acquired audio data and lyrics text according to preset rules to generate a music video file containing an audio track and a visual text track.

[0289] Music videos are synchronized digital media files that integrate the song's audio stream with the lyrics track and are aligned along the timeline. A music video may include a static cover frame as the starting screen, a dynamic waveform as a background visualization, and transition animations associated with the lyrics.

[0290] In one possible implementation, the music video can be a short video file containing a synchronized subtitle track. For example, the terminal device inputs a 30-second song file and timestamped lyrics into a media assembly engine, allocates subtitle display intervals according to playback time, and generates a music video that can be highlighted and scrolled in sync with the lyrics in the interface player.

[0291] Alternatively, the music video can be a multimedia container that encapsulates an audio track and a text-to-image compositing layer. For example, during the assembly stage, lyrics text is drawn on a solid-color background layer and font scaling effects are triggered to match the song's beat. It is then merged and encoded with the audio stream to output a media file suitable for full-screen playback in a graphical user interface.

[0292] The embodiments of this application are not limited to the specific packaging form of music videos. For example, they can be short videos with subtitle tracks, multimedia containers with graphic composite layers, or packaging media that simultaneously overlays multiple visual elements.

[0293] In step S1930, specifically, after the terminal device completes the assembly and generation of the music video, it renders the generated music video to the designated media display area of ​​the graphical user interface.

[0294] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0295] After the terminal device displays the second song generation result in the graphical user interface, it reads the corresponding song file and associated lyrics text from local storage, and calls the media assembly service to combine the audio and lyrics into a 30-second music video according to the playback timeline. Subsequently, a media player overlay pops up in the graphical user interface, loads the assembled music video into the player, and plays it automatically, while simultaneously highlighting the currently sung segment in the lyrics display area.

[0296] Exemplary embodiments of this disclosure also provide a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the methods described above.

[0297] Implementing the above method steps using a computer program has the following technical effects: This disclosure provides a song generation method, apparatus, electronic device, and program product. By using the semantic features of the original input text as the matching basis for semantic caching, and displaying the corresponding song generation results in the case of cache hit and miss respectively, user input with similar semantics can be effectively identified and reused in the cache layer, thereby reducing repeated triggering of the complete generation chain. While improving system processing efficiency, it also enhances the user interaction experience through rapid generation result feedback, and enriches the content feedback dimension of music generation games through the result presentation mechanism of hit and miss.

[0298] In one implementation, the computer program product can be a tangible product, such as a computer-readable storage medium storing a computer program. The readable storage medium can be based on electrical, magnetic, optical, electromagnetic, infrared, or other signals, and includes, but is not limited to: random access memory (RAM), read-only memory (ROM), magnetic tape, floppy disk, flash memory, hard disk drive (HDD), solid-state drive (SSD), etc. For example, the computer program product can be a non-volatile storage medium storing a computer program, such as read-only memory, NAND flash memory, etc.

[0299] In one implementation, the computer program product can be an intangible product. For example, the computer program product can be a virtual digital product, such as an executable file or installation package containing a computer program.

[0300] Computer program code can be written in one or more programming languages. Examples of programming languages ​​include C, Java, and C++. Program code can execute entirely on the user's computing device, partially on the user's computing device, or as a standalone software package. It can also execute partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, such as a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via an internet connection provided by a mobile network operator).

[0301] Computer programs can be carried or transmitted via signals such as electrical, magnetic, optical, electromagnetic, and infrared rays. Electronic devices can convert signals carrying computer programs into digital signals, thereby running the computer programs. When a computer program runs on an electronic device, its code is used to cause the electronic device to execute (more specifically, to be executed by the processor of the electronic device) the method steps of various embodiments of this disclosure.

[0302] Exemplary embodiments of this disclosure also provide an electronic device, which may be the first client 110, the second client 120, or the server 130 described above. The electronic device includes a processor and a memory. The memory stores executable instructions for the processor, such as computer programs. The processor executes these executable instructions to perform the method steps of various exemplary embodiments of this disclosure.

[0303] Implementing the above method steps using electronic devices has the following technical advantages: This disclosure provides a song generation method, apparatus, electronic device, and program product. By using the semantic features of the original input text as the matching basis for semantic caching, and displaying the corresponding song generation results in the case of cache hit and miss respectively, user input with similar semantics can be effectively identified and reused in the cache layer, thereby reducing repeated triggering of the complete generation chain. While improving system processing efficiency, it also enhances the user interaction experience through rapid generation result feedback, and enriches the content feedback dimension of music generation games through the result presentation mechanism of hit and miss.

[0304] The following is for reference. Figure 3 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 3 The electronic device 1100 shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0305] like Figure 3As shown, the electronic device 1100 may include: a processor 1110, a memory 1120, a bus 1130, an I / O (input / output) interface 1140, and a network adapter 1150.

[0306] Memory 1120 may include volatile memory, such as RAM 1121 and cache unit 1122, and may also include non-volatile memory, such as ROM 1123. Memory 1120 may also include one or more program modules 1124, such program modules 1124 including, but not limited to: operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 1124 may include the modules in the above-described apparatus.

[0307] The processor 1110 may include one or more processing units, such as an AP (Application Processor), a modem processor, a GPU (Graphics Processing Unit), an ISP (Image Signal Processor), a controller, an encoder, a decoder, a DSP (Digital Signal Processor), a baseband processor, and / or an NPU (Neural-Network Processing Unit).

[0308] The processor 1110 can be used to execute executable instructions stored in the memory 1120 to perform method steps of various embodiments of the present disclosure.

[0309] Bus 1130 is used to connect different components of electronic device 1100 and may include a data bus, an address bus and a control bus.

[0310] Electronic device 1100 can communicate with one or more external devices 1200 (such as keyboard, mouse, external controller, etc.) through I / O interface 1140.

[0311] Electronic device 1100 can communicate with one or more networks via network adapter 1150. For example, network adapter 1150 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 1150 can communicate with other modules of electronic device 1100 via bus 1130.

[0312] In one embodiment, the electronic device 1100 further includes a display for displaying a graphical user interface.

[0313] although Figure 3 As not shown in the diagram, other hardware and / or software modules may also be configured in the electronic device 1100, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (Redundant Arrays of Independent Disks) systems, tape drives, and data backup storage systems.

[0314] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, apparatus, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or an implementation combining hardware and software aspects, which may be referred to as "circuit," "module," or "system," respectively.

[0315] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

Claims

1. A song generation method, characterized in that, The method of providing a graphical user interface via a terminal device includes: The input area is displayed through the graphical user interface. The graphical user interface receives input commands for the input area and controls the acquisition of the original input text. Based on the original input text, a matching process is performed in the semantic cache to determine the cached matching result, wherein the semantic cache uses the semantic features of the original input text as the matching basis; If the cache matching result indicates a cache hit, the first song generation result corresponding to the cache matching result is displayed through the graphical user interface; If the cache matching result indicates a cache miss, a second song generation result is displayed through the graphical user interface, wherein the second song generation result is generated based on the original input text.

2. The method according to claim 1, characterized in that, The step of displaying the input area through the graphical user interface includes: displaying the input area and the style selection area through the graphical user interface; The step of receiving input instructions for the input area through the graphical user interface and controlling the acquisition of the original input text includes: receiving input instructions for the input area and the style selection area through the graphical user interface, and controlling the acquisition of the original input text and style selection parameters; wherein, the second song generation result is generated based on the original input text and the style selection parameters.

3. The method according to claim 2, characterized in that, The step of generating the second song result based on the original input text and the style selection parameters includes: If the cache matching result indicates a cache miss, target lyrics are generated according to the original input text and the style selection parameters, based on preset conditions, so that the target lyrics cover neighboring inputs that are semantically similar to the original input text. Generate the second song generation result corresponding to the target lyrics.

4. The method according to claim 3, characterized in that, The step of generating target lyrics according to preset conditions includes: Based on the target prompt information corresponding to the style selection parameters, the original input text is rewritten while preserving the intent of the original input text and reducing the degree of literal expression locking, to obtain the target lyrics.

5. The method according to claim 1, characterized in that, The steps for performing matching processing in the semantic cache include: Select parameters based on style to determine the target cache partition; The matching process is performed within the target cache partition, wherein the step of performing the matching process within the target cache partition includes: performing matching within the target cache partition without comparing with other cache partitions, so as to isolate different cache partitions from each other.

6. The method according to claim 3, characterized in that, After the step of generating the second song generation result corresponding to the target lyrics, the method further includes: The semantic features corresponding to the original input text, the target lyrics, and the second song generation result are treated as a cache data and written into the semantic cache.

7. The method according to claim 6, characterized in that, The step of writing the semantic features corresponding to the original input text, the target lyrics, and the second song generation result as a cached data entry into the semantic cache includes: The semantic features corresponding to the original input text, the target lyrics, and the second song generation result are stored as atomic pairs in the local storage path.

8. The method according to claim 3, characterized in that, The step of generating target lyrics according to preset conditions, so that the target lyrics cover neighboring inputs with semantic similarity to the original input text, includes: Generate target lyrics that retain the intent of the original input text but are not locked to the literal expression of the original input text, so that the target lyrics can be reused by multiple inputs within the same semantic neighborhood.

9. The method according to claim 6, characterized in that, The step of writing the semantic features corresponding to the original input text, the target lyrics, and the second song generation result as a cached data entry into the semantic cache includes: The semantic features corresponding to the original input text are written into the semantic cache as the starting point of the new neighborhood; If a subsequent input hits the semantic cache, the subsequent input is assigned to the new neighborhood, so that the neighborhood of the semantic cache dynamically expands as cache entries increase.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 9.

Images