Time sequence-based clock-in terminal audio file asynchronous multipath transmission merging method
By adopting a time series-based asynchronous multi-channel transmission merging method on the punch-in terminal, uploading and merging audio files and description files every minute, the problem of large storage space and high production costs of the punch-in terminal is solved, and cost saving and efficiency improvement is achieved effect.
Patent Information
- Application Number
- CN202411600893.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-11
- Publication Date
- 2025-02-18
Smart Images
Figure CN119484508A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of data transmission, and in particular to a time sequence-based asynchronous multiplexing and merging method for audio files of a punch-in terminal. Background Art
[0002] A clock-in terminal is an intelligent device used to record and track the attendance of individuals or groups at events, work or other forms of attendance. For example, a piano practice clock-in terminal needs to upload the piano practice audio file and the audio file description file to the backend service for analysis and processing. Only one piano practice file and the corresponding description file need to be uploaded for each piano practice. This method requires a large storage space, resulting in a high production cost of the clock-in terminal.
[0003] In order to save the production cost of the clock-in terminal, for example, to control the terminal side file system space to 32M, the present invention proposes a time-series-based clock-in terminal audio file asynchronous multiplexing merging method, and the clock-in terminal is set to upload an audio file and a description file every minute, and then the back-end service merges the uploaded time series audio files and updates the description file. The terminal determines that all the recording files have been uploaded and sends an end mark to the back-end service. Summary of the invention
[0004] The purpose of the present invention is to propose a time-series-based asynchronous multiplexing and merging method for clock-in terminal audio files, which can compress the storage space on the terminal side and save the production cost of the clock-in terminal.
[0005] To achieve the above object, the technical solution of the present invention is: a time-series-based method for asynchronous multiplexing and merging of audio files of a punch-in terminal, which specifically comprises the following steps: S1. Start recording and clocking in. The clocking in terminal generates recording files and description files every minute and uploads them to the backend service. S2. The backend service receives the recording file and description file sent by the clock-in terminal, processes them and returns the processing result; S3. The clock-in terminal determines whether the corresponding recording file and description file are uploaded successfully according to the processing result returned by the backend service. If the processing is successful, the corresponding recording file and description file are deleted. Otherwise, they are uploaded again. If the maximum number of retransmissions is exceeded, the corresponding recording file and description file are discarded. S4. After the recording and clocking in are completed and the recording file and description file are uploaded, the clocking in terminal sends an end request to the backend service, and the backend service returns the processing result.
[0006] Preferably, the content recorded in the description file includes: file sequence number fileIndex, punch-in time, valid and invalid values of the recording file, terminal device SN, and punch-in ID; the valid and invalid values of the recording file record the invalid duration of the punch-in; the file sequence number fileIndex is 1, indicating the start of uploading, and the file sequence number fileIndex of the description file uploaded in the next minute is the file sequence number fileIndex of the description file uploaded in the previous minute plus 1, and fileIndex is 0, indicating the end of uploading.
[0007] Preferably, the S2 specifically comprises the following steps: S21, the backend service obtains the recording file and description file sent by the terminal, and saves the file in a temporary path; and queries the recording record table according to the terminal device SN and punch-in ID of the description file; the contents stored in the recording record table include: terminal device SN, punch-in ID, processed fileIndex, processed recording file path, processed description file path, punch-in status, and file processing status; The backend service performs corresponding operations according to the file number fileIndex of the description file and the processed fileIndex of the recording record table: if fileIndex==1, execute S22; if fileIndex<processed fileIndex+1, execute S23; if fileIndex=processed fileIndex+1, execute S24; if fileIndex>processed fileIndex+1, execute S25; if fileIndex==0, execute S26; S22, fileIndex==1, indicating that the file starts to be uploaded; determine whether the recording record queried in S21 exists; if so, return successful processing; if not, copy the recording file and the description file to the official path, add a new recording record in the recording record table, save the terminal device SN, punch-in ID, and file sequence number fileIndex of the description file to the terminal device SN, punch-in ID, and processed fileIndex of the recording record table respectively, save the official path of the recording file and the description file to the processed recording file path and processed description file path of the recording record table, set the punch-in status to start, and set the file processing status to normal; S23, fileIndex<processed fileIndex+1, indicating that the fileIndex has been processed, and directly returns the processing success; S24, fileIndex=processed fileIndex+1, indicating that the recording file and description file corresponding to the fileIndex are exactly the files expected to be sent; after merging the recording files and updating the description files, the recording record table is updated and the processing success is returned; S25, fileIndex> processed fileIndex+1, indicating that there are files that are missed; check whether there is an unprocessed file with the file number of processed fileIndex+1 in the temporary path, if so, merge the recording files according to the unprocessed file, update the description file and update the recording record table; after updating the processed fileIndex, continue to process the unprocessed file with the file number of processed fileIndex+1 in the temporary path until the processed fileIndex+1 is the currently uploaded fileIndex, and process the file corresponding to the currently uploaded fileIndex according to S24; if the processed fileIndex+1 is still not equal to the currently uploaded fileIndex, it means that there are still files that have not been uploaded, and directly return the processing success; S26, fileIndex==0, indicating that the file upload is complete; the backend service merges the recording files, updates the description files, and updates the recording record table for all the unprocessed files whose file numbers are greater than the processed fileIndex stored in the temporary path in the order of the file numbers. After completion, the check-in status is changed to ended, and the files and folders under the temporary path are deleted.
[0008] Preferably, merging the recording files specifically includes merging the currently processed recording file with the merged recording file, wherein the merged recording file refers to the recording file under the path of the processed recording file corresponding to the recording record table.
[0009] Preferably, updating the description file specifically includes adding the valid and invalid values of the recording file in the currently processed description file to the valid and invalid values of the recording file in the processed description file, and the processed description file refers to the description file under the corresponding processed description file path in the recording record table.
[0010] Preferably, updating the recording record table specifically involves using the fileIndex of the currently processed description file to update the corresponding processed fileIndex in the recording record table; and updating the updated save path of the current description file to the processed description file path of the recording record table, and updating the merged save path of the current recording file to the processed recording file path of the recording record table.
[0011] Preferably, in S26, when the unprocessed files are merged into recording files, the description files are updated, and the recording record table is updated in sequence, if there is a missing file in the middle, the next file of the missing file will continue to be processed until all unprocessed files are processed, and the corresponding file processing status in the recording record table is changed to a missing processing status.
[0012] Compared with the prior art, the present invention has the following beneficial effects: The present invention uploads the audio file and the description file to the back-end service every minute through the asynchronous multiplex transmission merging method, thereby reducing the file storage space on the terminal side and saving the production cost of the punch-in terminal. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] Figure 1 It is a flow chart of the present invention. DETAILED DESCRIPTION
[0014] The following is combined with Figure 1 , the technical solution of the present invention is specifically described.
[0015] The present invention proposes a time-series-based asynchronous multiplexing and merging method for clock-in terminal audio files, which specifically includes the following steps: S1. Start recording and clocking in. The clocking in terminal generates recording files and description files every minute and uploads them to the backend service. S2. The backend service receives the recording file and description file sent by the clock-in terminal, processes them and returns the processing result; S3. The clock-in terminal determines whether the corresponding recording file and description file are uploaded successfully according to the processing result returned by the backend service. If the processing is successful, the corresponding recording file and description file are deleted. Otherwise, they are uploaded again. If the maximum number of retransmissions is exceeded, the corresponding recording file and description file are discarded. S4. After the recording and clocking in are completed and the recording file and description file are uploaded, the clocking in terminal sends an end request to the backend service, and the backend service returns the processing result.
[0016] In this embodiment, the content recorded in the description file includes: file sequence number fileIndex, punch-in time, valid and invalid values of the recording file, terminal device SN, and punch-in ID; the valid and invalid values of the recording file record the invalid duration of the punch-in; the file sequence number fileIndex is 1, indicating the start of uploading, and the file sequence number fileIndex of the description file uploaded in the next minute is the file sequence number fileIndex of the description file uploaded in the previous minute plus 1, and fileIndex is 0, indicating the end of uploading.
[0017] For example, in the description file {"fileIndex":1,"pianoTime":"20241101143122","values":[{"time":0,"state":0},{"time":2010,"state":1},{"time":56160,"state":0}],"sn":"244E10074577","id":"20241101143122"}, fileIndex is the current file sequence number; pianoTime is the clock-in time; values are valid or invalid values of the recording file, which records the invalid duration of the clock-in, and processes it in milliseconds. State 1 indicates that the clock-in is valid, and state 0 indicates that the clock-in is invalid, that is, the clock-in from 0 to 2010 milliseconds in the recording file indicates that the clock-in is invalid, and the clock-in from 2010 to 56160 is valid; sn is the device SN, which is the unique identification code of the terminal clock-in; id: clock-in ID, which is the unique field of the clock-in machine.
[0018] In this embodiment, S2 specifically includes the following steps: S21, the backend service obtains the recording file and description file sent by the terminal, and saves the file in a temporary path; and queries the recording record table according to the terminal device SN and punch-in ID of the description file; the contents stored in the recording record table include: terminal device SN, punch-in ID, processed fileIndex, processed recording file path, processed description file path, punch-in status, and file processing status; The backend service performs corresponding operations according to the file number fileIndex of the description file and the processed fileIndex of the recording record table: if fileIndex==1, execute S22; if fileIndex<processed fileIndex+1, execute S23; if fileIndex=processed fileIndex+1, execute S24; if fileIndex>processed fileIndex+1, execute S25; if fileIndex==0, execute S26; S22, fileIndex==1, indicating that the file starts to be uploaded; determine whether the recording record queried in S21 exists; if so, return successful processing; if not, copy the recording file and the description file to the official path, add a new recording record in the recording record table, save the terminal device SN, punch-in ID, and file sequence number fileIndex of the description file to the terminal device SN, punch-in ID, and processed fileIndex of the recording record table respectively, save the official path of the recording file and the description file to the processed recording file path and processed description file path of the recording record table, set the punch-in status to start, and set the file processing status to normal; S23, fileIndex<processed fileIndex+1, indicating that the fileIndex has been processed, and directly returns the processing success; S24, fileIndex=processed fileIndex+1, indicating that the recording file and description file corresponding to the fileIndex are exactly the files expected to be sent; after merging the recording files and updating the description files, the recording record table is updated and the processing success is returned; S25, fileIndex> processed fileIndex+1, indicating that there are files that are missed; check whether there is an unprocessed file with the file number of processed fileIndex+1 in the temporary path, if so, merge the recording files according to the unprocessed file, update the description file and update the recording record table; after updating the processed fileIndex, continue to process the unprocessed file with the file number of processed fileIndex+1 in the temporary path until the processed fileIndex+1 is the currently uploaded fileIndex, and process the file corresponding to the currently uploaded fileIndex according to S24; if the processed fileIndex+1 is still not equal to the currently uploaded fileIndex, it means that there are still files that have not been uploaded, and directly return the processing success; S26, fileIndex==0, indicating that the file upload is complete; the backend service merges the recording files, updates the description files, and updates the recording record table for all the unprocessed files whose file numbers are greater than the processed fileIndex stored in the temporary path in the order of the file numbers. After completion, the check-in status is changed to ended, and the files and folders under the temporary path are deleted.
[0019] In this embodiment, merging recording files specifically includes merging the currently processed recording file with the merged recording file, where the merged recording file refers to the recording file under the path of the processed recording file corresponding to the recording record table.
[0020] In this embodiment, updating the description file specifically includes adding the valid and invalid values of the recording file in the currently processed description file to the valid and invalid values of the recording file in the processed description file, where the processed description file refers to the description file under the corresponding processed description file path in the recording record table.
[0021] In this embodiment, updating the recording record table specifically involves using the fileIndex of the currently processed description file to update the corresponding processed fileIndex in the recording record table; and updating the updated save path of the current description file to the processed description file path of the recording record table, and updating the merged save path of the current recording file to the processed recording file path of the recording record table.
[0022] In this embodiment, in S26, when the unprocessed files are merged into recording files, the description files are updated, and the recording record table is updated in sequence, if there is a missing file in the middle, the next file of the missing file will continue to be processed until all unprocessed files are processed, and the corresponding file processing status in the recording record table is changed to a missing processing status.
[0023] The above are preferred embodiments of the present invention. Any changes made according to the technical solution of the present invention, as long as the resulting functions do not exceed the scope of the technical solution of the present invention, belong to the protection scope of the present invention.
Claims
1. A time-series-based asynchronous multiplexing and merging method for clock-in terminal audio files, characterized in that: The specific steps include: S1. Start recording and clocking in. The clocking in terminal generates recording files and description files every minute and uploads them to the backend service. S2. The backend service receives the recording file and description file sent by the clock-in terminal, processes them and returns the processing result; S3. The clock-in terminal determines whether the corresponding recording file and description file are uploaded successfully according to the processing result returned by the backend service. If the processing is successful, the corresponding recording file and description file are deleted. Otherwise, they are uploaded again. If the maximum number of retransmissions is exceeded, the corresponding recording file and description file are discarded. S4. After the recording and clocking in are completed and the recording file and description file are uploaded, the clocking in terminal sends an end request to the backend service, and the backend service returns the processing result.
2. According to the time series-based method for asynchronous multiplexing and merging of clock-in terminal audio files according to claim 1, it is characterized in that: The contents recorded in the description file include: file number fileIndex, punch-in time, valid and invalid values of the recording file, terminal device SN, and punch-in ID; the valid and invalid values of the recording file record the invalid duration of the punch-in; the file number fileIndex is 1, indicating the start of uploading, and the file number fileIndex of the description file uploaded in the next minute is the file number fileIndex of the description file uploaded in the previous minute plus 1, and fileIndex is 0, indicating the end of uploading.
3. The method for asynchronous multiplexing and merging of audio files of a punch-in terminal based on time series according to claim 2, characterized in that: The S2 specifically includes the following steps: S21, the backend service obtains the recording file and description file sent by the terminal, and saves the file in a temporary path; and queries the recording record table according to the terminal device SN and punch-in ID of the description file; the contents stored in the recording record table include: terminal device SN, punch-in ID, processed fileIndex, processed recording file path, processed description file path, punch-in status, and file processing status; The backend service performs corresponding operations according to the file number fileIndex of the description file and the processed fileIndex of the recording record table: if fileIndex==1, execute S22; if fileIndex<processed fileIndex+1, execute S23; if fileIndex=processed fileIndex+1, execute S24; if fileIndex>processed fileIndex+1, execute S25; if fileIndex==0, execute S26; S22, fileIndex==1, indicating that the file starts to be uploaded; determine whether the recording record queried in S21 exists; if so, return successful processing; if not, copy the recording file and the description file to the official path, add a new recording record in the recording record table, save the terminal device SN, punch-in ID, and file sequence number fileIndex of the description file to the terminal device SN, punch-in ID, and processed fileIndex of the recording record table respectively, save the official path of the recording file and the description file to the processed recording file path and processed description file path of the recording record table, set the punch-in status to start, and set the file processing status to normal; S23, fileIndex<processed fileIndex+1, indicating that the fileIndex has been processed, and directly returns the processing success; S24, fileIndex=processed fileIndex+1, indicating that the recording file and description file corresponding to the fileIndex are exactly the files expected to be sent; after merging the recording files and updating the description files, the recording record table is updated and the processing success is returned; S25, fileIndex> processed fileIndex+1, indicating that there are files that are missed; check whether there is an unprocessed file with the file number of processed fileIndex+1 in the temporary path, if so, merge the recording files according to the unprocessed file, update the description file and update the recording record table; after updating the processed fileIndex, continue to process the unprocessed file with the file number of processed fileIndex+1 in the temporary path until the processed fileIndex+1 is the currently uploaded fileIndex, and process the file corresponding to the currently uploaded fileIndex according to S24; if the processed fileIndex+1 is still not equal to the currently uploaded fileIndex, it means that there are still files that have not been uploaded, and directly return the processing success; S26, fileIndex==0, indicating that the file upload is complete; the backend service merges the recording files, updates the description files, and updates the recording record table for all the unprocessed files whose file numbers are greater than the processed fileIndex stored in the temporary path in the order of the file numbers. After completion, the check-in status is changed to ended, and the files and folders under the temporary path are deleted.
4. The method for asynchronous multiplexing and merging of audio files of a punch-in terminal based on time series according to claim 3 is characterized in that: Merging recording files specifically includes merging the currently processed recording file with the merged recording file, where the merged recording file refers to the recording file under the path of the processed recording file corresponding to the recording record table.
5. The method for asynchronous multiplexing and merging of audio files of a punch-in terminal based on time series according to claim 3 is characterized in that: Updating the description file specifically includes adding the valid and invalid values of the recording file in the currently processed description file to the valid and invalid values of the recording file in the processed description file, wherein the processed description file refers to the description file under the corresponding processed description file path in the recording record table.
6. The method for asynchronous multiplexing and merging of audio files of a punch-in terminal based on time series according to claim 3 is characterized in that: Specifically, updating the recording record table includes using the fileIndex of the currently processed description file to update the corresponding processed fileIndex in the recording record table; and updating the updated save path of the current description file to the processed description file path in the recording record table, and updating the merged save path of the current recording file to the processed recording file path in the recording record table.
7. The method for asynchronous multiplexing and merging of audio files of a punch-in terminal based on time series according to claim 3 is characterized in that: In S26, when the unprocessed files are merged into recording files, the description files are updated, and the recording record table is updated in sequence, if there is a missing file in the middle, the next file of the missing file will continue to be processed until all unprocessed files are processed, and the corresponding file processing status in the recording record table is changed to a missing processing status.