A method of, and apparatus for, verification of audio content
A method for validating vocal audio recordings through unique text generation and correlation analysis addresses the challenge of distinguishing original from synthesized content, ensuring secure and efficient royalty management and synthetic voice generation.
Patent Information
- Authority / Receiving Office
- GB · GB
- Patent Type
- Applications
- Current Assignee / Owner
- HABLAB LONDON LTD
- Filing Date
- 2024-10-24
- Publication Date
- 2026-06-17
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
The present invention relates to an improved method of, and apparatus for, verification of audio content. Artists such as singers and spoken word artists have traditionally received royalties in respect of the commercial use of their vocal audio content. Traditional recording and playback methods have meant that it was relatively straightforward to identify where an artist’s work has been used inappropriately without consent. However, the recent advent of machine learning technology operable to simulate an artist's voice has posed significant challenges for the music industry. Using widely-available technology, it is relatively straightforward to train a computational speech synthesis model on an artist’s existing vocal work in order to generate new spoken or sung audio content that simulates, to a reasonable degree, the artist's voice. It is then possible to use such technology to generate “new” content from that artist. This poses several challenges for the industry. First, it poses a challenge to validate whether audio content originated directly from the artist or was synthesised. This has an impact on the quality and usage of material from the artist, as well as making it challenging to identify and generate royalty revenue. Secondly, this makes it challenging for an artist to retain control over their vocal signature and use of content which at least appears to originate from them. This reduces not only the future revenue they may generate but may also lead to inappropriate use of an artist’s vocal audio content. The present invention aims, in embodiments, to address these issues. The following introduces a selection of concepts in a simplified form in order to provide a foundational understanding of some aspects of the present disclosure. The following is not an extensive overview of the disclosure and is not intended to identify key or critical elements of the disclosure or to delineate the scope of the disclosure. The following merely summarizes some of the concepts of the disclosure as a prelude to the more detailed description provided thereafter. Several preferred aspects of the methods and systems according to the present invention are outlined below. According to a first aspect of the present invention there is provided a computer-implemented method for validating vocal audio recordings on a computing system, the method comprising the steps of: a) generating, using a first computational model, natural language training text for a user to vocalise, the training text being uniquely generated and comprising a complete set of phonetic units; b) recording vocal audio data relating to the user’s vocalisation of the natural language training text; c) performing, using a second computational model, text conversion on the recorded vocal audio data to generate verification text; d) comparing the training text and verification text to determine a correlation metric; and e) validating the recorded vocal audio data if the correlation metric exceeds a threshold value. In one embodiment, the phonetic units comprise phonemes. In one embodiment, the first computational model comprises a machine learning model. In one embodiment, the first computational model comprises a large language model (LLM). In one embodiment, step a) further comprises generating natural language training text based on user-specified parameters. In one embodiment, the user-specified parameter comprises a user-selected theme or subject. In one embodiment, step b) comprises recording vocal audio data relating to the user’s vocalisation of the natural language training text in a plurality of different registers. In one embodiment, step b) comprises recording first vocal audio data relating to the user’s vocalisation of the natural language training text in a first register and recording of further vocal audio data relating to the user’s vocalisation of the natural language training text in one or more further registers. In one embodiment, the user’s vocalisation of the natural language training text comprises the user singing the natural language training text. In one embodiment, the second computational model comprises a machine learning model. In one embodiment, the correlation metric in step d) comprises a percentage match between the training text and the verification text. In one embodiment, the threshold value for a percentage match is at least 70%. In one embodiment, the computing system comprises a server, a database and at least one user computing device connected via a network. In one embodiment, step b) is performed using a recording device of the user computing device. In one embodiment, step b) is performed using an audio recording device of the user computing device. In one embodiment, prior to step a) the method comprises: f) providing, on the user computing device, a user interface operable to authenticate a user. In one embodiment, prior to step a) the method comprises: f) providing, on the user computing device, a user interface operable to enable authentication of a user. In one embodiment, step b) further comprises presenting the generated natural language training text to the user through the user interface. In one embodiment, the user interface forms part of an application programming interface (API) In one embodiment, if the recorded vocal audio data is validated in step e), the method further comprises: g) associating the vocal audio data with the user and storing the vocal audio data on the database as validated vocal audio data. In one embodiment, if the recorded vocal audio data is validated in step e), the method further comprises: h) generating a validation certificate and associating the validation certificate with the stored validated vocal audio data. According to a second aspect of the present invention, there is provided a networked computer system comprising a server and at least one user computing device, the networked computer system comprising at least one hardware processor and at least one data storage device, the hardware processor being configured to execute the method of the first aspect. According to a third aspect of the present invention, there is provided a non-transitory computer readable medium comprising instructions configured when executed to perform the method of the first aspect. In a further aspect of the present invention there is provided a computer-implemented method for validating vocal audio recordings on a computing system, the method comprising the steps of: a) generating, using a first computational model, natural language training text for a user to vocalise, the training text being uniquely generated and comprising a set of phonetic units; b) recording vocal audio data relating to the user’s vocalisation of the natural language training text; c) performing, using a second computational model, text conversion on the recorded vocal audio data to generate verification text; d) comparing the training text and verification text to determine a correlation metric; and e) validating the recorded vocal audio data if the correlation metric exceeds a threshold value. In one embodiment, the set of phonetic units is a subset of the total number of phonetic units for the given natural language. In one embodiment, the set of phonetic units is a complete set of the total number of phonetic units for the given natural language. Embodiments of the present invention will now be described in detail with reference to the accompanying drawings, in which: Figure 1 shows a schematic diagram of a computing system according to an embodiment of the present invention; Figure 2 shows a detailed schematic diagram of components of the computing system of Figure 1 according to an embodiment; and Figure 3 shows a schematic diagram of a database of the computing system according to an embodiment; Figure 4 shows a flow chart of a method according to an embodiment; and Figure 5 shows a flow chart of a method according to a further embodiment. Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numbers are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same. Various examples and embodiments of the present disclosure will now be described. The following description provides specific details for a thorough understanding and enabling description of these examples. One of ordinary skill in the relevant art will understand, however, that one or more embodiments described herein may be practiced without many of these details. Likewise, one skilled in the relevant art will also understand that one or more embodiments of the present disclosure can include other features and / or functions not described in detail herein. Additionally, some well-known structures or functions may not be shown or described in detail below, so as to avoid unnecessarily obscuring the relevant description. The present invention relates to a method of, and apparatus for, verification of audio content. In embodiments, the present invention enables a user to generate a verified version of their own vocal audio content which can both verify the authenticity of a user and provide the necessary training data for a machine learning model to utilise the data to generate a sufficiently realistic synthetic version of the user’s voice. System structure Figure 1 shows a general schematic view of the structure and operation of the present invention. Figure 1 shows a computing system 100. The computing system 100 comprises a server 102 and a database 104. A plurality of client devices 106 may connect to the server 102 through a network 108. The network 108 may take any suitable form and may be a local network (for example, a Wi-Fi or Ethernet network), a cloud network (through internet or cellular communication connections) or a mixed network utilising both technologies. The database 104 may comprise data storage devices connected across a storage network (not shown). Alternatively, the database 104 may be local to the secure server 102 and / or may have access to a remote data store (not shown) for storage of larger files. The server 102 may, in embodiments, comprise a cloud-based server and server operations may be executed through cloud-based applications, web-based applications or other operations such as HTTP requests. The server 102 may, in embodiments, comprise one or more of a web server, an application server, or a cloud server. In embodiments, the server 102 may comprise a plurality of distributed resources commonly known as “containers” or “virtual machines”. The server 102 may comprise any suitable computer device, system, collection of computing devices or collections of computing system and may, in non-limiting examples, comprise any one or more of: one or more processors; one or more hardware or software controller devices; one or more memory devices; one or more user input devices; one or more output devices; and one or more communication devices. Any one or more of the processor, controller, or memory may be a physical, non-transitory, device or apparatus. The devices / apparatus may be electronic, opto-electronic or optical. The processor may, in principle, be any suitable processing device such as, but not limited to, a microprocessor, an application-specific instruction-set processor, a graphics processing unit (GPU / VPU), a physics processing unit (PPU), a digital signal processor, a network processor, a front end processor. The controller may be any suitable controller including any one or more of a controller chip, a controller board, a mainframe controller, an external controller or any other suitable controller. The controller may be, for example, a micro-controller. The memory may, in principle be any suitable memory including any one or more of: mechanical memory such as, but not limited to, magnetic tape drive, hard-drive, optical drive; volatile and non-volatile memory such as, but not limited to, RAM, DRAM, SRAM, SDRAM, T-RAM, Z-RAM, TTRAM, ROM, Mask ROM, PROM, EPROM, EEPROM, NVRAM. In use, users are able to communicate electronically with the server 102 and database 104 using the client devices 106. The client devices 106 may take any suitable form; for example, desktop computers, laptop computers, mobile telephones, smartphones, tablet computers or other computing devices. Each client device 106 comprises at least one hardware processor and a memory. In embodiments, the computing system 100 may comprise one or more defined Application Programming Interfaces (APIs) run on the client devices 102. Each API may have a user interface specific to the particular client device 102 (e.g. smartphone, tablet, PC etc.) that is being used. The user interface provides a portal through which the user can interact with the computing system, server 102 and secure database 104. In embodiments, data requests to the server 102 from the client devices 106 may be handled by the API of each client device 106. The components and operation of the computing system 100 will be discussed in further detail below with reference to Figure 2. It is noted here that while various components and operations have been described herein in terms of “modules”, “units” or “components,” these terms are not limited to single units or functions. Moreover, functionality attributed to some of the modules or components described herein may be combined and attributed to fewer modules or components. In addition, the specific location where components and operations of the present invention are performed is not material. For example, components may be located on one or more of the client devices 106, server 102 or elsewhere and operations may be performed locally on the client devices 106 or on the server 102 or the cloud as required. Figure 2 shows a schematic view of the operational components of the computer system 100. The computer system 100 comprises at least one hardware processor 110, at least one memory 112, and an I / O module 114. The I / O module 114 is operable to handle requests to / from the server 102 from the APIs of the client devices 106 across the network 108. The computer system 100 comprises a number of functional modules that will be described with respect to the validation process of the present invention. In embodiments, the present invention provides a validation process for authenticating audio content provided by an authenticated user for the purpose of training a machine learning algorithm. In embodiments, this comprises a process including the general steps of: user authentication; recording of training data vocal audio content; verification of the recorded training data; and certification and storage of verified vocal audio content. In this regard, the computing system comprises an authentication module 116, a recording module 118, a verification module 120 and a certification module 122. Authentication module 116 The authentication module 116 is operable to validate a user’s account. For example, the server 102 may comprise a secure server which can only be accessed by a user through a client device 106 API if the user has the correct credentials to set up an account and then apply the correct authentication details, e.g. username, password and / or PIN to enable the user to log on the computing system 100. In embodiments, a user account may only be set up with appropriate strong authentication and validation. This is to ensure that the user (which may be an artist or creator of content) is confirmed as genuine and that an account set up in the name of a particular artist or creator genuinely belongs to that artist or creator. In embodiments, the process may involve independent validation of the user’s details. This may comprise a process such as obtaining validation through a government ID scheme or other strong validation process based on the user’s credentials, personal details and / or biometric data as appropriate. Once the account has been validated and set up in the name of the artist or creator (i.e. the user), the user can then login using their authentication details. This may be through a user interface (not shown) on the client device 106 and operable to enable the user to enter authentication details and, if authenticated, access a secure environment therethrough. Any suitable user interface may be used, such as a graphical user interface (GUI) displayed on the client device 106. This may be presented through a browser window or a native display or window of the API. In embodiments, as part of the login process, the database 104 may comprise a user ID log table 104T comprising details of all valid user IDs 104T-n (where n = 1 to i) on the system. A schematic, non-limiting example of this is shown in Figure 3. Parameters associated with each user ID 104T-n may include user login data ulD such as username and password and / or PIN. In addition, each user ID may have personal validation data vID associated therewith. The personal validation data vID may be associated with data required to set up the user’s account and validate the user as genuine as described above. In addition, other stored data relating to training text uTT, audio data rTD and / or validation certificate data aUC may be stored against the user ID as will be described below. Privileges may be defined as required. Non-exhaustively, these may include a number of access or control rights including: right to view one or more user accounts or communications, access recorded data, access verification certificates and / or the right to reset passwords or any PIN numbers. Recording module 118 The function and operation of the recording module 118 is to generate unique training text which the user of the process is then requested to speak or sing. The resulting vocal utterances in the form of vocal audio signatures are recorded for further validation and processing. In this regard, the recording module 118 comprises two modules: a training text generator 124 and an audio recorder 126. The training text generator 124 is configured to generate natural language training text for the user to vocalise to generate the vocal audio signature. By this is meant training text in a suitable natural language. Any natural language may be used as appropriate. In embodiments, the generated natural language training text is unique to the user, i.e. is generated specifically for the user and the same text will not be generated for another user. In embodiments, the training text may be unique to the particular validation instance (i.e. the training text may be generated uniquely each time the user takes part in the process). By providing unique text generation, this ensures security of the validation process since the text will not be available elsewhere and so represents a potentially intractable problem to reproduce accurately by a third party looking to imitate an artist’s vocalisations by using artificially-generated language or excerpts from or modifications to the artist’s existing works. In embodiments, a further specification of the training text is to provide a complete set of training data for accurate machine learning training and therefore reproduction of the user’s voice. In order to do this to a required level of accuracy, then the recorded training data will need to contain all the necessary phonetic units of a given natural language to enable accurate training and reproduction in a suitable machine learning model. In embodiments, the phonetic units may comprise phonemes and the training text may contain all necessary phonemes in a given natural language. This may be a subset of the total number of phonemes in a given natural language. In embodiments, the training text contains a complete set of phonemes in a given natural language. A phoneme may be described as the "smallest unit of meaningful sound". A phoneme may comprise any set of similar speech sounds that is perceptually regarded by speakers of a natural language as a single basic sound of that natural language. In other words, a phoneme comprises the smallest possible phonetic unit that assists in distinguishing one word from another. All spoken natural languages contains phonemes and include both consonant and vowel phonemes. In embodiments, the natural language is English. The English language alphabet has 26 letters from which can be derived 44 phonemes. Each phoneme represents a different sound, including: 18 x consonants (individual consonant sounds e.g. b, c, d) 6 x digraphs (2 consonants working together e.g. th, sh, ch); 12 x monophthongs (vowels making a single sound e.g. the 'a' in cat); and 8 x diphthongs (2 vowels creating a single syllable e.g. 'oi' in coin). In embodiments, the training text uTT may comprise a plurality of sentences sufficient in length and number to cover the necessary phonetic units of the natural language. In embodiments, one or more paragraphs (each comprising multiple sentences) may be generated as training text. In embodiments, the training text comprises the minimum number of sentences and / or paragraphs to reproduce the necessary number of phonemes in the pre-defined natural language. In embodiments, the training text may comprise the minimum number of sentences to capture a complete set of phonemes in the pre-defined natural language. In embodiments, the training text may comprise the minimum number of sentences to achieve the above aims whilst being linguistically accurate, linguistically coherent and configured to be read or sung by the user during a training data recording session. The training text generator 124 may generate training text in any suitable manner or through any suitable means. For example, a first computational model in the form of a random text generator may be used to generate sufficient words that all phonetic units are covered in the text so generated. However, the inventors have found that coherent sentences are easier for a user to parse and vocalise. Therefore, the training text generator 124 may comprise a first computational model in the form of a suitable natural language processing model to generate linguistically correct sentences that may be vocalised more effectively by the user. In this regard, the training text generator 124 may comprise a natural language processing module. This may involve any suitable system and method. For example, the training text generator 124 may comprise a natural language processing module utilising a symbolic approach where a set of rules for manipulating symbols, coupled with a dictionary lookup and / or devising heuristic rules for stemming. Alternatively, a machine learning (ML) model may be used as part of the natural language processing module. A statistical ML model may be used. Alternatively, a ML model comprising a neural network may be used. In embodiments, a language model (LM) or large language model (LLM) may be used. Examples may include the Generative Pretrained Transformer (GPT) series from OpenAI series and BERT from Google. If an LLM is used, it may be accessed through a suitable API. A further advantage of the use of a suitable LLM to generate the necessary text is that the user may optionally select a topic, theme or context for the text generation. This has numerous benefits. First, if an LLM is continually instructed simply to generate a predetermined number of paragraphs including the 44 English phonemes without further direction, after a period of time repetition may occur which would potentially weaken the security element because the uniqueness of each text generation would be compromised. However, by allowing the user to select and define subject matter for the text, the expectation for unique paragraphs is increased substantially, and the risk of similar paragraph generation is consequently diminished. Secondly, by providing the user with more apparent control and input into the process, the user is more engaged with the process, resulting in a more positive, natural sounding, training data. A non-limiting example of suitable text generated by one of the above systems and comprising a complete set of phonetic units (in this embodiment, phonemes) is shown below: The quick brown fox jumps over the lazy dog while zigzagging near a yellow, buzzing beehive. Suddenly, a sleek, crimson snake slithers quietly through the emerald grass, hissing softly as it approaches a wren perched on the cedar branch. Curious, the wren chirps a series of intricate melodies, its beak clicking with each staccato note. Meanwhile, a jittery chipmunk scurries beneath the oak, nibbling on an acorn, its tiny teeth chattering in rhythm. A gust of wind whispers through the willow trees, rustling leaves and swaying the slender stems of wildflowers. Beyond the hill, a silent owl hoots once before swooping down to catch a gleaming silver fish from the sparkling brook. Nearby, a mother sheep bleats softly to her lambs, their woolly coats dappled with dew. On a distant shore, waves crash against jagged rocks, each splash echoing in the cool, salty air. A jaguar, spotted and silent, stalks its prey with stealthy grace, its paws padding on the damp earth. In the town square, a bell tolls twelve times, resonating through cobblestone streets where a group of children play hopscotch, their laughter ringing out. A man in a top hat tips his brim as he walks past a market stall brimming with ripe oranges, apples, and plums. The sun dips below the horizon, casting long shadows as twilight envelops the scene. Soon, stars twinkle above, and the world falls into a hushed, tranquil silence. Once the user’s training text uTT is generated by the training text generator 124, this is displayed to a user through the user interface of the API (or any suitable user interface) with suitable instructions to record the training data. The generated text data uTT is also stored in the database 104 against the user’s specific user ID as shown in Figure 3. The audio recorder 126 is then operable to record, through use of a suitable microphone (not shown) on the client device 106, the generated training text. In embodiments, the audio recorder 126 may comprise any suitable digital recording software or hardware. Any suitable sampling rate and bit depth may be used. For example, the data may be recorded at standard sampling rates of 44.1 kHz or 48 kHz. Alternatively, higher sampling rates of 96 kHz or 192 kHz may be used if equipment and storage space allows. 192 kHz is the highest sampling rate in mainstream use. Higher sampling rates provide better quality training data if resources allow. However, the inventors have found that the approach of the present invention enables efficient capture of accurate training data even when using relatively standard recording equipment such as the microphones on smartphones or personal computers. For example, for training data, timbre and tempo are significant elements which can be captured reliably using conventional audio recording equipment. This is in contrast to existing approaches to training data capture which may require an artist to attend a recording studio. By enabling the recordal of training data on a personal computing device such as client device 106, the process is more convenient for a user and increases the likelihood of uptake of the process by artists and content creators. In embodiments, the user is asked to record their vocalisation of the training text (e.g. the recording relates to spoken or sung training text) in a plurality of different registers. This provides different vocal ranges and in common with, in embodiments, the complete set of phonetic units of a given natural language provides rich and comprehensive training data. If the user wishes to re-record their vocalisation at any point, this is possible. Once finalised, the audio data is temporarily stored pending action by the verification module 120. By vocalisation is meant a series of vocal utterances by the user (who may be an artist or content creator) which may be either sung or spoken (or combinations of both) as appropriate. Verification module 120 The verification module 120 is operable to verify the authenticity of the recorded data recorded by the audio recorder 126. The verification module 120 comprise two elements - a voice to text reconversion (VTR) module 128 and an authentication module 130. The VTR module 128 may comprise a second computational model in the form of a speech recognition module which may comprise a speech-to-text model. The second computational model may comprise a machine learning model that is trained for a vocal content recognition task such as to predict spoken or sung words in the recorded audio data input data. In other words, VTR module is configured to process and convert spoken or sung language in audio signal data into written text. The VTR module may take any suitable form and may, for example, utilise statistical algorithms like Hidden Markov models (HMM) and / or dynamic time warping (DTW). Alternatively, an attention model may be used. Neural network models may also be used. The VTR module 128 may have a number of different sub-models, such as a punctuation model or a model to identify capital letters or other special text. If a machine learning model is used for the VTR module, a training process may be used to define the parameters of the model such as cost functions, input size, number of layers and node weights. Once trained on a training dataset, the speech recognition model 102A may be trained to output a prediction result (e.g. written text) for an unseen vocal data input. In embodiments, the VTR module 128 may comprise a software component of an application executable on the client device 106. In embodiments, this may be through a third party API or the API of the computing system 100 on the client device 106. In embodiments, the VTR module 128 may utilise libraries or external script data.. Additionally or alternatively, the VTR module 128 may be implemented in hardware or a combination of hardware and software. In embodiments, the VTR module 128 takes the vocal audio data obtained by the audio recorder 126 and generates a text reconversion output therefrom. The authentication module 130 is operable to compare the original training text data with the text reconversion output generated by the VTR module 128 and generate a correlation metric representative of the commonality between the two text sets. In embodiments, the correlation metric may comprise a percentage match. In embodiments, the correlation metric may comprise a percentage word match. In embodiments, punctuation and case or grammar may be ignored. In embodiments, a percentage match which exceeds a predetermined threshold is considered to be a pass, and below this value to be a fail. In embodiments, the predetermined threshold may be 70%. In embodiments, the predetermined threshold may be 80%. In embodiments, the predetermined threshold may be 90%. If the process fails, then the authentication process fails and the audio data obtained by the audio recorder 126 is rejected. The user is notified of the failure and may have the option of repeating the process or exiting. Repeated failures may result in the user being blocked from the process. Certification module 122 If the authentication module 130 generates a pass from the comparison of the training text and reconverted text, then the certification module 122 is operable to generate an authenticated user certificate allC which is stored against the user ID for the user. The authenticated user certificate may take any suitable form. In embodiments, the authenticated user certificate may comprise a specific validation or authorisation that may be accepted by third parties (e.g. record labels or streaming services) as evidence and proof of authentic training data of the user (i.e. artist or content creator). In embodiments, the authenticated user certificate may be associated with a blockchain entry. In embodiments, the authenticated user certificate may be associated with a blockchain hash. As is known, a blockchain consists of scripts for entering, storing and accessing information. A blockchain is a distributed system which collects transaction information and enters it into blocks of a predetermined size (e.g. 4 MB). Once a block is full, the data in the block is processed utilising a cryptographic hash function to generate a hexadecimal block hash, which is entered into the header of the next block and encrypted with that information. In addition, the audio data recorded by the audio recorder 126 is then stored in the database 104 against the user’s specific user ID as recorded training data rTD. The recorded training data rTD is, advantageously, a full set of training data containing the user’s vocalisation of all necessary phonemes in the natural language of the training text and which may be recorded in a plurality of registers. In embodiments, the full set of training data comprises a complete set of phonemes in the natural language of the training text. This has significant advantages over known arrangements. First, a complete set of training data is recorded which may then be used to train a suitable machine learning model to generate a sufficiently accurate synthetic representation of the user’s spoken and / or singing voice. Secondly, this is done together with a verification process which is effectively invisible to the user if successful, providing validated training data in a single smooth and efficient process for the user. Thirdly, it has been found that training data of sufficient quality can be obtained using the present approach where conventional microphones or other recording devices of the client device(s) 106 are used. Therefore, methods of the present invention provide a secure, validated and convenient process that the user can perform without the need to attend a recording studio or engage with separate certification and validation procedures. Authentication method A method according to an embodiment of the present invention will now be described with reference to Figure 4. Figure 4 shows a flow chart of an authentication method according to an embodiment of the present invention. It is to be noted that the embodiment of Figure 4 is exemplary and the steps of the method may be executed in any suitable order as would be apparent to the skilled person. Step 200: Request user details At step 200, a user is prompted to login to their account. As noted above, in embodiments, a user account may only be set up with appropriate strong authentication and validation. This is to ensure that the user (which may be an artist or creator of content) is confirmed as genuine and that an account set up in the name of a particular artist or creator genuinely belongs to that artist or creator. In embodiments, the process may involve independent validation of the user’s details. This may comprise a process such as obtaining validation through a government ID scheme or other strong validation process based on the user’s credentials, personal details and / or biometric data as appropriate. Once the account has been validated and set up in the name of the artist or creator (i.e. the user), the user can then login using their authentication details in step 200. At step 200, the user enters their username and password into a user interface of the API. The general process is the same irrespective of the computing device 10 used by the user. In embodiments, the server 102 may comprise a secure server which can only be accessed by a user through a client device 106 API if the user has the correct credentials to set up an account and then the correct authentication details, e.g. username, password and / or PIN to enable the user to log on the computing system 100. As part of the login process, the database 104 may comprise a user ID log table 104T comprising details of all valid user IDs 104T-n (where n = 1 to i) on the system. Parameters associated with each user ID 104T-n may include user login data ulD such as: username and password or PIN. In addition, each user ID may have personal validation data vID associated therewith. The personal validation data vID may be associated with data required to set up the user’s account and validate the user as genuine as described above. Whilst the above process is generic to all types of client devices 106, the format of the login process and initiation of the login process differs depending upon the type of client device 106 being used. The following, non-limiting, examples are discussed below. For an internet browser, the homepage will contain dialogue boxes for username and password and the method for logging in to the secure server 102 is then carried out. Alternatively, the login process can be carried out through an application (or “app”). This may be the case for a smartphone or tablet, and increasingly for desktop and laptop PCs. Once the application is selected and opened, the login details can be entered and the login process completed. When the username and password or PIN have been entered by the user, the method proceeds to step 202. Step 202: API request to server At step 202, an API (application program interface) request is made to the server 102 based on the details supplied by the user. The user interface is operable to communicate with the secure server 102 through suitable exchange requests (e.g. GET or POST HTTPS URL) using a defined API. The method proceeds to step 204. Step 204: Authenticate username and password The server 102 is operable to check the combination of username and password / PIN. If the combination exists in the database 104, the method proceeds to step 206. If the combination does not exist, the login fails and method proceeds to step 222 where the process terminates. Step 206: Enable user access At step 206, the user is authenticated and provided with access to the secure server 102 and database 104. This may be through a suitable user interface, such as a graphical user interface (GUI) displayed on the client device 106. This may be through a browser window or a native display or window of the API. Step 208: Request user input for text data Step 208 may be optional. If implemented, the user may be asked to select a topic, theme or context for the text generation. In embodiments, this has numerous advantages as described above. First, this avoids likely repetition which may potentially weaken the security element because the uniqueness of each text generation would be compromised. By allowing the user to select and define subject matter for the text, the expectation for unique paragraphs is increased substantially, and the risk of similar paragraph generation is consequently diminished. Secondly, by providing the user with more apparent control and input into the process, the user is more engaged with the process, resulting in a more positive, natural sounding, training data. Once the user topic for the text is selected in step 208, the method proceeds to step 210. Step 210: Generate training text At step 210, the recording module 118 and training text generator 124 are utilised to generate natural language training text uTT for the user to vocalise to generate vocal audio signatures. In embodiments, the generated natural language training text is unique to the user and may be unique to the particular validation instance (i.e. the training text may be generated uniquely each time the user takes part in the process). By providing unique text generation, this ensures security of the validation process since the text will not be available elsewhere and so represents an intractable problem to reproduce accurately by a third party looking to imitate an artist by using artificially-generated language or excerpts from the artist’s existing works. In embodiments, a further specification of the training text is to provide a complete set of training data for accurate machine learning training and therefore reproduction of the user’s voice. In order to do this to a required level of accuracy, then the recorded training data will need to contain all the necessary phonetic units of a given natural language to enable accurate training and reproduction in a suitable machine learning model. In embodiments, the phonetic units may comprise phonemes and the training text may contain all necessary phonemes in a given natural language. This may be a subset of the total number of phonemes in a given natural language. In embodiments, the training text contains a complete set of phonemes in a given natural language. A phoneme may be described as the "smallest unit of meaningful sound". A phoneme may comprise any set of similar vocal sounds that is perceptually regarded by speakers or singers of a natural language as a single basic sound of that natural language. In other words, a phoneme comprises the smallest possible phonetic unit that assists in distinguishing one word from another. In embodiments, the training text uTT may comprise a plurality of sentences to cover the necessary phonetic units of the natural language. In embodiments, one or more paragraphs (each comprising multiple sentences) may be generated as training text. In embodiments, the training text comprises the minimum number of sentences and / or paragraphs to reproduce the necessary number of phonemes in the pre-defined natural language. In embodiments, the training text may comprise the minimum number of sentences to capture a complete set of phonemes in the pre-defined natural language. In embodiments, the training text may comprise the minimum number of sentences to achieve the above aims whilst being linguistically accurate, linguistically coherent and configured to be read or sung by the user during a training data recording session. The training text generator 124 generates training text in any suitable manner or through any suitable means as discussed above. In embodiments, a suitable natural language processing model may be utilised as part of the training text generator 124 to generate linguistically correct sentences that may be vocalised more effectively by the user. In this regard, the training text generator 124 may comprise a natural language processing module. This may involve any suitable system and method. For example, the training text generator 124 may comprise a natural language processing module utilising a symbolic approach where a set of rules for manipulating symbols, coupled with a dictionary lookup and / or devising heuristic rules for stemming. Alternatively, a machine learning (ML) model may be used as part of the natural language processing module. A statistical ML model may be used. Alternatively, a ML model comprising a neural network may be used. In embodiments, a language model (LM) or large language model (LLM) may be used. Examples may include the generative pretrained transformer (GPT) series from OpenAI series and BERT from Google. If an LLM is used, it may be accessed through a suitable API. A non-limiting example of suitable text generated by one of the above systems and comprising a complete set of phonetic units (in this embodiment, phonemes) is shown below: The quick brown fox jumps over the lazy dog while zigzagging near a yellow, buzzing beehive. Suddenly, a sleek, crimson snake slithers quietly through the emerald grass, hissing softly as it approaches a wren perched on the cedar branch. Curious, the wren chirps a series of intricate melodies, its beak clicking with each staccato note. Meanwhile, a jittery chipmunk scurries beneath the oak, nibbling on an acorn, its tiny teeth chattering in rhythm. A gust of wind whispers through the willow trees, rustling leaves and swaying the slender stems of wildflowers. Beyond the hill, a silent owl hoots once before swooping down to catch a gleaming silver fish from the sparkling brook. Nearby, a mother sheep bleats softly to her lambs, their woolly coats dappled with dew. On a distant shore, waves crash against jagged rocks, each splash echoing in the cool, salty air. A jaguar, spotted and silent, stalks its prey with stealthy grace, its paws padding on the damp earth. In the town square, a bell tolls twelve times, resonating through cobblestone streets where a group of children play hopscotch, their laughter ringing out. A man in a top hat tips his brim as he walks past a market stall brimming with ripe oranges, apples, and plums. The sun dips below the horizon, casting long shadows as twilight envelops the scene. Soon, stars twinkle above, and the world falls into a hushed, tranquil silence. Once the training text uTT is generated by the training text generator 124 in step 210, this is displayed to a user through the API with suitable instructions. The generated text data uTT is also stored in the database 104 against the user’s specific user ID as shown in Figure 3. Step 212: Record training vocal data The training text generator 124 is utilised in step 210 to generate unique training text uTT which the user of the process is then requested to vocalise (i.e. speak or sing) in step 212. The resulting vocalisations of the training text in the form of vocal audio signatures are recorded for further validation and processing. By vocalisation is meant a series of vocal utterances made by the user (who may be an artist or content creator) which may be either sung or spoken (or combinations of both) as appropriate and relates to the training text presented to the user. In step 212, the user vocalises (i.e. sings or speaks) the phrases generated in step 210 which are recorded by the audio recorder 126, through use of a suitable microphone (not shown) on the client device 106. In embodiments, the audio recorder 126 may comprise any suitable digital recording software or hardware. Any suitable sampling rate and bit depth may be used. For example, the data may be recorded at standard sampling rates of 44.1 kHz or 48 kHz. Alternatively, higher sampling rates of 96 kHz or 192 kHz may be used if equipment and storage space allows. 192 kHz is the highest sampling rate in mainstream use. Higher sampling rates provide better quality training data if resources allow. In embodiments, the user is asked to record their vocal utterances (e.g. spoken or sung training text) in a plurality of different registers. This provides different vocal ranges and in common with the complete set of phonetic units of a given natural language provides rich and comprehensive training data. If the user wishes to re-record their vocalisations of the training text at any point, this is possible within step 212. Once finalised, the vocal audio data relating to the vocalisation of the generated training text is temporarily stored pending action by the verification module 120. Step 214: Re-convert recorded vocal audio data to text At step 214, the VTR module 128 executes a speech-to-text model trained for a vocal content recognition task to predict spoken or sung words in the recorded audio data input data. In this step, the VTR module 128 processes and converts the vocal audio data (comprising spoken or sung language as discussed above) into written text. In other words, the VTR module 128 takes the vocal audio data obtained by the audio recorder 126 and generates a text reconversion output therefrom. The VTR module may take any suitable form and may, for example, utilise statistical algorithms like Hidden Markov models (HMM) and / or dynamic time warping (DTW). Alternatively, an attention model may be used. Neural network models may also be used. The VTR module 128 may have a number of different sub-models, such as a punctuation model or a model to identify capital letters or other special text. If a machine learning model is used for the VTR module, a training process may be used to define the parameters of the model such as cost functions, input size, number of layers and node weights. Once trained on a training dataset, the speech recognition model 102A may be trained to output a prediction result (e.g. written text) for an unseen vocal data input. In embodiments, the VTR module 128 may comprise a software component of an application executable on the client device 106. In embodiments, this may be through a third party API or the API of the computing system 100 on the client device 106. In embodiments, the VTR module 128 may utilise libraries or external script data.. Additionally or alternatively, the VTR module 128 may be implemented in hardware or a combination of hardware and software. Once the text reconversion data has been generated in step 214, the method proceeds to step 216. Step 216: Compare reconversion data with training text At step 216, the authentication module 130 is operable to compare the original training text data with the text reconversion output generated by the VTR module 128 and generate a correlation metric representative of the commonality between the two text sets. In embodiments, the correlation metric may comprise a percentage match. In embodiments, the correlation metric may comprise a percentage word match. In embodiments, punctuation and case or grammar may be ignored. In embodiments, a percentage match which exceeds a predetermined threshold is considered to be a pass, and below this value to be a fail. In embodiments, the predetermined threshold may be 70%. In embodiments, the predetermined threshold may be 80%. In embodiments, the predetermined threshold may be 90%. If the match is successful, the method proceeds to step 218. If the process fails, then the method proceeds to step 220. Step 218: Certification of recorded audio data At step 218, if the authentication module 130 generates a pass from the comparison of the training text and reconverted text in step 216, then the certification module 122 is operable to generate an authenticated user certificate which is stored against the user ID for the user. The authenticated user certificate may take any suitable form. In embodiments, the authenticated user certificate may comprise a specific validation or authorisation that may be accepted by third parties (e.g. record labels or streaming services) as evidence and proof of authentic training data of the user (i.e. artist or content creator). In embodiments, the authenticated user certificate may be associated with a blockchain entry. In embodiments, the authenticated user certificate may be associated with a blockchain hash. As is known, a blockchain consists of scripts for entering, storing and accessing information. A blockchain is a distributed system which collects transaction information and enters it into blocks of a predetermined size (e.g. 4 MB). Once a block is full, the data in the block is processed utilising a cryptographic hash function to generate a hexadecimal block hash, which is entered into the header of the next block and encrypted with that information. In addition, the audio data recorded by the audio recorder 126 is then stored in the database 104 against the user’s specific user ID as recorded training data rTD. The recorded training data rTD is, advantageously, a full set of training data containing the user’s vocalisation of all necessary phonemes in the natural language of the training text and which may be recorded in a plurality of registers. In embodiments, the full set of training data comprises a complete set of phonemes in the natural language of the training text. The recorded data can then be used as effective and comprehensive training data. This has significant advantages over known arrangements. First, a complete set of training data is recorded which may then be used to train a suitable machine learning model to generate a sufficiently accurate synthetic representation of the user’s spoken and / or singing voice. Secondly, this is done together with a verification process which is effectively invisible to the user if successful, providing validated training data in a single smooth and efficient process for the user. Thirdly, it has been found that training data of sufficient quality can be obtained using the present approach where conventional microphones or other recording devices of the client device(s) 106 are used. Therefore, methods of the present invention provide a secure, validated and convenient process that the user can perform without the need to attend a recording studio or engage with separate certification and validation procedures. Step 220: Authentication fail At step 220, if either the username / password / PIN check (step 204) fail, then the user has not been validated to access the computing system 100 and the process ends with a login rejection. The user may attempt to login to the process for another set number of times (e.g. 3). Optionally, after a set number of unsuccessful attempts to login to the server 102 and database 104, the user may be blocked from further attempts either permanently or for a set period of time. Step 222: Authentication fail At step 222, the authentication process has failed and the audio data obtained by the audio recorder 126 is rejected. The user is notified of the failure and may have the option of repeating the process or exiting. Repeated failures may result in the user being blocked from the process. In summary, the present invention has numerous benefits over the known art. In embodiments, the present invention enables a user to generate a verified version of their own vocal audio content which can both verify the authenticity of a user and provide the necessary training data for a machine learning model to utilise the data to generate a sufficiently realistic synthetic version of the user’s voice or vocal utterances. In embodiments, these elements create a fluid pipeline where the security process is seamlessly and invisibly built into the utility process. Users will feel like they are simply recording their voice for a training model set, and if they follow the process, they could be completely unaware of the security processes. However, if a user attempts to use ripped audio from historic files of an artist, then the process will reject them. Embodiments of the present invention alleviate one of the biggest threats to vocalists and actors that ML models could be used in combination with historical work to replicate their trade. Embodiments provide robust validation so that authentic artist’s work can be validated appropriately. Variations will be apparent to the skilled person. In embodiments, the computing system may be modular and utilise cloud- or networkbased systems. This is described above in relation to the computing system 100. In the above method of Figure 4, certain steps may be carried out outside the server 102, database 104 and client computer 106 utilising external APIs, plugins or software components forming part of the computing system 100 but not local to the server 102 and client computer 106. An exemplary embodiment showing this is shown in Figure 5. Figure 5 shows the flow chart of Figure 4 where the various method steps are partitioned by execution configuration. As shown, steps 210, 214 and 216 may, in embodiments, be executed by APIs, plugins, or data / computational resources which are external to the server 102 and client device 106. In such cases, data is exchanged across the network 108 between the server 102, client device 106 and external resource as required. An advantage of a modular arrangement is that the different processes in the networked system may be updated and upgraded as required whilst retaining the functionality of the present invention for the user of the computing system 100. The methods described herein may be embodied in one or more pieces of software. The software is preferably held or otherwise encoded upon a memory device such as, but not limited to, any one or more of, a hard disk drive, RAM, ROM, solid state memory or other suitable memory device or component configured to software. The methods may be realised by executing / running the software. Additionally or alternatively, the methods may be hardware encoded. The method encoded in software or hardware is preferably executed using one or more processors. The memory and / or hardware and / or processors are preferably comprised as, at least part of one or more servers and / or other suitable computing systems. In this specification, unless expressly otherwise indicated, the word "or" is used in the sense of an operator that returns a true value when either or both of the stated conditions are met, as opposed to the operator "exclusive or" which requires only that one of the conditions is met. The word "comprising" is used in the sense of "including" rather than to mean "consisting of'. All prior teachings above are hereby incorporated herein by reference. No acknowledgement of any prior published document herein should be taken to be an admission or representation that the teaching thereof was common general knowledge in Australia or elsewhere at the date thereof. Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and / or software components set forth herein may be combined into composite components comprising software, hardware, and / or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and / or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa. Software, in accordance with the present disclosure, such as program code and / or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and / or computer systems, networked and / or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and / or separated into sub-steps to provide features described herein. While various operations have been described herein in terms of “modules”, “units” or “components,” it is noted that that terms are not limited to single units or functions. Moreover, functionality attributed to some of the modules or components described herein may be combined and attributed to fewer modules or components. Further, whilst the present invention has been described with reference to specific embodiments and examples, those examples are intended to be illustrative only and are not intended to limit the invention. It will be apparent to those of ordinary skill in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the scope of the invention.
Claims
1. A computer-implemented method for validating vocal audio recordings on a computing system, the method comprising the steps of:a) generating, using a first computational model, natural language training text for a user to vocalise, the training text being uniquely generated and comprising a complete set of phonetic units;b) recording vocal audio data relating to the user’s vocalisation of the natural language training text;c) performing, using a second computational model, text conversion on the recorded vocal audio data to generate verification text;d) comparing the training text and verification text to determine a correlation metric; ande) validating the recorded vocal audio data if the correlation metric exceeds a threshold value.
2. A computer-implemented method according to claim 1, wherein the phonetic units comprise phonemes.
3. A computer-implemented method according to claim 1 or 2, wherein the first computational model comprises a machine learning model.
4. A computer-implemented method according to claim 3, wherein the first computational model comprises a large language model (LLM).
5. A computer-implemented method according to any one of the preceding claims, wherein step a) further comprises generating natural language training text based on user-specified parameters.
6. A computer-implemented method according to claim 5, wherein the user-specified parameter comprises a user-selected theme or subject.
7. A computer-implemented method according to any one of the preceding claims, wherein step b) comprises recording vocal audio data relating to the user’s vocalisation of the natural language training text in a plurality of different vocal registers.
8. A computer-implemented method according to claim 7, wherein step b) comprises recording first vocal audio data relating to the user’s vocalisation of the natural language training text in a first register and recording further vocal audio data relating to the user’s vocalisation of the natural language training text in one or more further registers.
9. A computer-implemented method according to any one of the preceding claims, wherein the user’s vocalisation of the natural language training text comprises the user singing the natural language training text.
10. A computer-implemented method according to any one of the preceding claims, wherein the second computational model comprises a machine learning model.
11. A computer-implemented method according to any one of the preceding claims, wherein the correlation metric in step d) comprises a percentage match between the training text and the verification text.
12. A computer-implemented method according to claim 11, wherein the threshold value for a percentage match is at least 70%.
13. A computer-implemented method according to any one of the preceding claims, wherein the computing system comprises a server, a database and at least one user computing device connected via a network.
14. A computer-implemented method according to claim 13, wherein step b) is performed using an audio recording device of the user computing device.
15. A computer-implemented method according to claim 13 or 14, wherein prior to step a) the method comprises:f) providing, on the user computing device, a user interface operable to enable authentication of a user.
16. A computer-implemented method according to any one of the preceding claims, wherein step b) further comprises presenting the generated natural language training text to the user through the user interface.
17. A computer-implemented method according to claim 14, 15 or 16, wherein the user interface forms part of an application programming interface (API) operable to access the server and database.
18. A computer-implemented method according to any one of claims 13 to 17, wherein, if the recorded vocal audio data is validated in step e), the method further comprises:g) associating the vocal audio data with the user and storing the vocal audio data on the database as validated vocal audio data.5 19. A computer-implemented method according to any one of claims 13 to 18, wherein, ifthe recorded vocal audio data is validated in step e), the method further comprises:h) generating a validation certificate and associating the validation certificate with the stored validated vocal audio data.
20. A networked computer system comprising a server and at least one user computing to device, the networked computer system comprising at least one hardware processor and at least one data storage device, the hardware processor being configured to execute the method of any one of claims 1 to 19.
21. A non-transitory computer readable medium comprising instructions configured when executed to perform the method as claimed in any one of claims 1 to 19.15s