Multi-format audio data management method and system based on local storage

Abstract

The invention discloses a multi-format audio data management method based on local storage, and relates to the technical field of multimedia playing. The method comprises the following steps: after a media player application program is awakened / started, carrying out running environment check to obtain a running environment abstract, searching a storage space of a media player, screening supported media files from the storage space to generate a file list, extracting metadata of the media files, generating an abstract list according to the extracted metadata, and sending the abstract list to the media player application program; loading the abstract list into a memory of the media player, and loading a decoding library according to the media file to be played and the operation environment abstract to generate a playlist; after the decoding library is loaded, the media files are played according to the playlist, whether the media files in the storage space are changed or not is monitored, and if the media files in the playlist are changed, the abstract list and the playlist are updated. According to the invention, the media player can adapt to various media formats, and whether the media file changes can be monitored in real time during playing and a user can be prompted.

Description

Technical Field

[0001] This invention relates to the field of multimedia playback technology, and specifically to a method and system for managing multi-format audio data based on local storage. Background Technology

[0002] DD+ format is a new audio coding format proposed by Dolby Laboratories. It is an enhanced version of AC-3 coding and is also known as E-AC-3. This format offers higher bit rates (up to 6.144 Mbit / s), supports more audio channels (up to 13.1 channels), and uses improved coding techniques to reduce data rates (for example, 5.1 channel audio can be transmitted at a data rate of 256 kbit / s).

[0003] The adoption of the DD+ format has significantly improved audio quality, especially in environments supporting high bitrates and multi-channel configurations, providing users with a more immersive listening experience. This format not only satisfies consumers with high-end audio needs but also, to some extent, promotes the dissemination and development of high-definition film and television content.

[0004] However, the music player that comes with the Android system cannot play DD+ format audio files, which affects the user's listening experience. Summary of the Invention

[0005] The purpose of this invention is to propose a multi-format audio data management method based on local storage to solve the problem that Android music players cannot parse DD+ format audio files, and at least provide a beneficial option or create conditions.

[0006] To achieve the above technical objectives, the technical solution of the present invention is as follows: In a first aspect, the present invention provides a method for managing multi-format audio data based on local storage, the method comprising the following steps: Step 1: After being woken up / started, the media player application performs a runtime environment check to obtain a runtime environment summary; Step 2: The media player application searches the storage space of the media player running the media player application, searches the storage space for media files supported by the media player application, and generates a file list; Step 3: The media player application extracts the metadata of the media files based on the file list, and generates a summary list based on the extracted metadata; Step 4: The media player application loads the summary list into the media player's memory, and loads the decoding library according to the media file to be played and the runtime environment summary to generate a playlist; Step 5: After loading the decoding library, the media player application plays media files according to the playlist and monitors whether any media files in the storage space have changed. If the media files in the playlist have changed, the summary list and the playlist are updated.

[0007] Further, in step 1, the sub-step of the media player application checking the runtime environment and obtaining a runtime environment summary after being woken up / started is as follows: After being woken up / started, the media player application detects the current runtime environment, which includes the Android OS version, CPU architecture, CPU encoding and decoding capabilities, DRM support level, and SD card read / write permission acquisition status, and generates a runtime environment summary based on the current runtime environment.

[0008] Preferably, if the media player application does not obtain read / write permissions for the SD card, the user is prompted on the GUI to confirm and obtain permissions.

[0009] Preferably, the CPU architecture is one of armeabi, armeabi-v7a, arm64-v8a, x86, RISC-V, MIPS, or MIPS64.

[0010] Preferably, if the CPU architecture cannot be read, the CPU architecture field of the runtime environment summary is set to armeabi.

[0011] Further, in step 2, the sub-step of the media player application searching the storage space of the media player running the media player application and searching the storage space for media files supported by the media player application is as follows: if the media player application obtains read / write permissions for the media player's storage space, it traverses the media files supported by the media player application in the media player's storage space; if the media player application cannot obtain read / write permissions for the media player's storage space, it exits the media player application. Generate a file list based on the media file.

[0012] Preferably, the media player application has a built-in list of supported media file formats, and the media files supported by the media player application are determined by comparing the file extension of the media file with the built-in list of supported media file formats.

[0013] Preferably, the list of supported media file formats for the media player application is determined by the runtime environment summary.

[0014] Preferably, the media player application is hard-coded to support the following formats: MP3, WMA, WAV, APE, FLAC, OGG, AAC, AC3, EC3, and DD+.

[0015] Preferably, the file list includes the path of the media file in the storage space.

[0016] Further, in step 3, the sub-step of the media player application extracting metadata from the media files based on the file list and generating a summary list based on the extracted metadata is as follows: The file list is loaded into the Android system cache. The media player application reads the metadata of the media files in the file list, generates a summary list based on the read metadata, and stores it in the data directory of the media player application.

[0017] Preferably, the metadata includes the format of the media file, the decoding library required to play the media file, file size, checksum, format, file name, artist, album, duration, and file path.

[0018] Preferably, the checksum is generated based on the size of the media file and one or more sub-items of the metadata.

[0019] Further, in step 4, the sub-step of the media player application loading the summary list into the media player's memory and loading the decoding library according to the media file to be played and the runtime environment summary to generate the playlist is as follows: the media player application loads the summary list into the media player's memory, loads the decoding library according to the media file selected by the user and the runtime environment summary, generates the playlist, and stores it in the data folder of the media player application.

[0020] Preferably, the playlist includes the path to the media file to be played and the corresponding decoding library for the media file. The decoding library is a dynamic .so library, which is provided by the media player application and stored in the jniLibs directory of the media player application. The jniLibs directory contains corresponding decoding libraries for different CPU architectures and different formats.

[0021] Preferably, if the media file is in DD+ format, the decoding library is set to libHwAudio_dcvdev.so.

[0022] Further, in step 5, after the media player application loads the decoding library, it plays media files according to the playlist and monitors whether any media files in the storage space have changed. If the media files in the playlist have changed, the sub-step of updating the summary list and the playlist is as follows: The media player application creates a background startup service monitoring mechanism by listening to system broadcasts. It obtains information about whether the media files in the playlist have changed through these broadcasts. If the media files in the playlist have changed, it retrieves the changed media files, reads their metadata, and updates the summary list and the playlist.

[0023] Preferably, all undefined variables in this invention, if not explicitly defined, can be manually set thresholds.

[0024] Secondly, the present invention provides a multi-format audio data management system based on local storage, the system comprising: System interaction module: used for runtime environment checks to obtain a runtime environment summary, loading dynamic .so libraries, and receiving system broadcasts to obtain changes in media files; Media file scanning module: The media file scanning module is used to scan the storage space of the media player and generate a file list, summary list, and playlist; Media file playback module: used to play the corresponding media files according to the playlist; Playlist update module: When the system interaction module detects a change in any media file in the playlist, it updates the file list, the summary list, and the playlist.

[0025] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method for managing multi-format audio data based on local storage provided in the first aspect of the present invention.

[0026] Fourthly, the present invention provides an electronic device, comprising: a memory storing a computer program thereon; and a processor for executing the computer program in the memory to implement the steps of the method for managing multi-format audio data based on local storage provided by the present invention.

[0027] Compared with the prior art, the present invention has the following beneficial technical effects: This media player application enables the media player to adapt to multiple media formats, dynamically monitor changes in media files within storage space, and update the audio file list in real time, reducing audio list loading time. It also supports loading custom libraries, allowing the media player application to play DD+ format audio or other formats. Attached Figure Description

[0028] Figure 1 A flowchart of a multi-format audio data management method based on local storage provided by the present invention; Figure 2 This is a schematic block diagram of a multi-format audio data management system based on local storage, according to an embodiment of the present invention. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. The specific embodiments described herein are only for explaining the invention and are not intended to limit the invention.

[0030] It should also be understood that the following embodiments are only used to further illustrate the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-essential improvements and adjustments made by those skilled in the art based on the above description of the present invention are within the scope of protection of the present invention. The specific process parameters, etc., in the following examples are merely examples within a suitable range; that is, those skilled in the art can make appropriate selections within the range based on the description herein, and are not intended to be limited to the specific values ​​in the examples below.

[0031] The following is an exemplary description of a multi-format audio data management method based on local storage provided by the present invention.

[0032] like Figure 1 The diagram shows a flowchart of a multi-format audio data management method based on local storage. The following section will combine... Figure 1 This invention describes a method for managing multi-format audio data based on local storage according to an embodiment of the present invention. The method includes the following steps: Step 1: After being woken up / started, the media player application performs a runtime environment check to obtain a runtime environment summary; Step 2: The media player application searches the storage space of the media player running the media player application, searches the storage space for media files supported by the media player application, and generates a file list; Step 3: The media player application extracts the metadata of the media files based on the file list, and generates a summary list based on the extracted metadata; Step 4: The media player application loads the summary list into the media player's memory, and loads the decoding library according to the media file to be played and the runtime environment summary to generate a playlist; Step 5: After loading the decoding library, the media player application plays media files according to the playlist and monitors whether any media files in the storage space have changed. If the media files in the playlist have changed, the summary list and the playlist are updated.

[0033] Further, in step 1, the sub-step of the media player application checking the runtime environment and obtaining a runtime environment summary after being woken up / started is as follows: After being woken up / started, the media player application detects the current runtime environment, which includes the Android OS version, CPU architecture, CPU encoding and decoding capabilities, DRM support level, and SD card read / write permission acquisition status, and generates a runtime environment summary based on the current runtime environment.

[0034] Preferably, if the media player application does not obtain read / write permissions for the SD card, the user is prompted on the GUI to confirm and obtain permissions.

[0035] Preferably, the CPU architecture is one of armeabi, armeabi-v7a, arm64-v8a, x86, RISC-V, MIPS, or MIPS64.

[0036] Preferably, if the CPU architecture cannot be read, the CPU architecture field of the runtime environment summary is set to armeabi.

[0037] Further, in step 2, the sub-step of the media player application searching the storage space of the media player running the media player application and searching the storage space for media files supported by the media player application is as follows: if the media player application obtains read / write permissions for the media player's storage space, it traverses the media files supported by the media player application in the media player's storage space; if the media player application cannot obtain read / write permissions for the media player's storage space, it exits the media player application. Generate a file list based on the media file.

[0038] Preferably, the media player application has a built-in list of supported media file formats, and the media files supported by the media player application are determined by comparing the file extension of the media file with the built-in list of supported media file formats.

[0039] Preferably, the list of supported media file formats for the media player application is determined by the runtime environment summary.

[0040] Preferably, the media player application is hard-coded to support the following formats: MP3, WMA, WAV, APE, FLAC, OGG, AAC, AC3, EC3, and DD+.

[0041] Preferably, the file list includes the path of the media file in the storage space.

[0042] Further, in step 3, the sub-step of the media player application extracting metadata from the media files based on the file list and generating a summary list based on the extracted metadata is as follows: The file list is loaded into the Android system cache. The media player application reads the metadata of the media files in the file list, generates a summary list based on the read metadata, and stores it in the data directory of the media player application.

[0043] Preferably, the metadata includes the format of the media file, the decoding library required to play the media file, file size, checksum, format, file name, artist, album, duration, and file path.

[0044] Preferably, the checksum is generated based on the size of the media file and one or more sub-items of the metadata.

[0045] Preferably, the verification code is the MD5 hash of the media file (a widely used cryptographic hash function used to ensure the integrity and consistency of information).

[0046] Further, in step 4, the sub-step of the media player application loading the summary list into the media player's memory and loading the decoding library according to the media file to be played and the runtime environment summary to generate the playlist is as follows: the media player application loads the summary list into the media player's memory, loads the decoding library according to the media file selected by the user and the runtime environment summary, generates the playlist, and stores it in the data folder of the media player application.

[0047] Preferably, the playlist includes the path to the media file to be played and the corresponding decoding library for the media file. The decoding library is a dynamic .so library, which is provided by the media player application and stored in the jniLibs directory of the media player application. The jniLibs directory contains corresponding decoding libraries for different CPU architectures and different formats.

[0048] Preferably, *.so (Shared Object, usually with the extension .so) is a dynamic link library file, which is a technology for calling third-party programs. This invention does not innovate on the .so technology, but only adopts the form of .so dynamic link library file. The working principle and working method of *.so dynamic link library file will not be described in detail here.

[0049] The media player application, at runtime, dynamically loads the decoding library's *.so file using Java Native Interface (JNI) technology by calling code and following the interface specification of the .so algorithm dynamic link library file. Preferably, if the media file is in DD+ format, the decoding library is set to libHwAudio_dcvdev.so.

[0050] Preferably, the following is a piece of source code for a .so file: ffmpeg_jni.c++ #include<android / log.h> #include<jni.h> #include<stdlib.h> extern "C" { #ifdef __cplusplus #define __STDC_CONSTANT_MACROS #ifdef _STDINT_H #undef _STDINT_H #endif #include<stdint.h> #endif #include<libavcodec / avcodec.h> #include<libavutil / channel_layout.h> #include<libavutil / error.h> #include<libavutil / opt.h> #include<libswresample / swresample.h> } #define LOG_TAG "ffmpeg_jni" #define LOGE(...) \ ((void)__android_log_print(ANDROID_LOG_ERROR, LOG_TAG, __VA_ARGS__)) #define LIBRARY_FUNC(RETURN_TYPE, NAME, ...) \ extern "C" { \ JNIEXPORT RETURN_TYPE \ Java_com_google_android_exoplayer2_ext_ffmpeg_FfmpegLibrary_##NAME( \ JNIEnv *env, jobjectthiz, ##__VA_ARGS__); \ } \ JNIEXPORT RETURN_TYPE \ Java_com_google_android_exoplayer2_ext_ffmpeg_FfmpegLibrary_##NAME( \ JNIEnv *env, jobjectthiz, ##__VA_ARGS__) #define AUDIO_DECODER_FUNC(RETURN_TYPE, NAME, ...) \ extern "C" { \ JNIEXPORT RETURN_TYPE \ Java_com_google_android_exoplayer2_ext_ffmpeg_FfmpegAudioDecoder_##NAME(\ JNIEnv *env, jobjectthiz, ##__VA_ARGS__); \ } \ JNIEXPORT RETURN_TYPE \ Java_com_google_android_exoplayer2_ext_ffmpeg_FfmpegAudioDecoder_##NAME( \ JNIEnv *env, jobjectthiz, ##__VA_ARGS__) #define ERROR_STRING_BUFFER_LENGTH 256 / / Output format corresponding to AudioFormat.ENCODING_PCM_16BIT. static const AVSampleFormat OUTPUT_FORMAT_PCM_16BIT = AV_SAMPLE_FMT_S16; / / Output format corresponding to AudioFormat.ENCODING_PCM_FLOAT. static const AVSampleFormat OUTPUT_FORMAT_PCM_FLOAT = AV_SAMPLE_FMT_FLT; static const int AUDIO_DECODER_ERROR_INVALID_DATA = -1; static const int AUDIO_DECODER_ERROR_OTHER = -2; / ** * Returns the AVCodec with the specified name, or NULL if it is notavailable. * / AVCodec *getCodecByName(JNIEnv *env, jstringcodecName); / ** * Allocates and opens a new AVCodecContext for the specified codec,passing the * provided extraData as initialization data for the decoder if it isnon-NULL. * Returns the created context. * / AVCodecContext *createContext(JNIEnv *env, AVCodec *codec,jbyteArrayextraData, jbooleanoutputFloat, jintrawSampleRate, jintrawChannelCount); / ** * Decodes the packet into the output buffer, returning the number ofbytes * written, or a negative AUDIO_DECODER_ERROR constant value in thecase of an * error. * / int decodePacket(AVCodecContext *context, AVPacket *packet, uint8_t *outputBuffer, int outputSize); / ** * Transforms ffmpeg AVERROR into a negative AUDIO_DECODER_ERRORconstant value. * / int transformError(int errorNumber); / ** * Outputs a log message describing the avcodec error number. * / void logError(const char *functionName, int errorNumber); / ** * Releases the specified context. * / void releaseContext(AVCodecContext *context); jintJNI_OnLoad(JavaVM *vm, void *reserved) { JNIEnv *env; if (vm->GetEnv(reinterpret_cast<void **>(&env), JNI_VERSION_1_6) !=JNI_OK) { return -1; } avcodec_register_all(); return JNI_VERSION_1_6; } LIBRARY_FUNC(jstring, ffmpegGetVersion) { return env->NewStringUTF(LIBAVCODEC_IDENT); } LIBRARY_FUNC(jint, ffmpegGetInputBufferPaddingSize) { return (jint)AV_INPUT_BUFFER_PADDING_SIZE; } LIBRARY_FUNC(jboolean, ffmpegHasDecoder, jstringcodecName) { return getCodecByName(env, codecName) != NULL; } AUDIO_DECODER_FUNC(jlong, ffmpegInitialize, jstringcodecName, jbyteArrayextraData, jbooleanoutputFloat, jintrawSampleRate, jintrawChannelCount) { AVCodec *codec = getCodecByName(env, codecName); if (!codec) { LOGE("Codec not found."); return 0L; } return (jlong)createContext(env, codec, extraData, outputFloat,rawSampleRate, rawChannelCount); } AUDIO_DECODER_FUNC(jint, ffmpegDecode, jlong context,jobjectinputData, jintinputSize, jobjectoutputData, jintoutputSize){ if (!context) { LOGE("Context must be non-NULL."); return -1; } if (!inputData || !outputData) { LOGE("Input and output buffers must be non-NULL."); return -1; } if (inputSize< 0) { LOGE("Invalid input buffer size: %d.", inputSize); return -1; } if (outputSize< 0) { LOGE("Invalid output buffer length: %d", outputSize); return -1; } uint8_t *inputBuffer = (uint8_t *)env->GetDirectBufferAddress(inputData); uint8_t *outputBuffer = (uint8_t *)env->GetDirectBufferAddress(outputData); AVPacket packet; av_init_packet(&packet); packet.data = inputBuffer; packet.size = inputSize; return decodePacket((AVCodecContext *)context, &packet,outputBuffer, outputSize); } AUDIO_DECODER_FUNC(jint, ffmpegGetChannelCount, jlong context) { if (!context) { LOGE("Context must be non-NULL."); return -1; } return ((AVCodecContext *)context)->channels; } AUDIO_DECODER_FUNC(jint, ffmpegGetSampleRate, jlong context) { if (!context) { LOGE("Context must be non-NULL."); return -1; } return ((AVCodecContext *)context)->sample_rate; } AUDIO_DECODER_FUNC(jlong, ffmpegReset, jlongjContext,jbyteArrayextraData) { AVCodecContext *context = (AVCodecContext *)jContext; if (!context) { LOGE("Tried to reset without a context."); return 0L; } AVCodecIDcodecId = context->codec_id; if (codecId == AV_CODEC_ID_TRUEHD) { / / Release and recreate the context if the codec is TrueHD. / / TODO: Figure out why flushing doesn't work for this codec. releaseContext(context); AVCodec *codec = avcodec_find_decoder(codecId); if (!codec) { LOGE("Unexpected error finding codec %d.", codecId); return 0L; } jbooleanoutputFloat = (jboolean)(context->request_sample_fmt == OUTPUT_FORMAT_PCM_FLOAT); return (jlong)createContext(env, codec, extraData, outputFloat, / * rawSampleRate= * / -1, / * rawChannelCount= * / -1); } avcodec_flush_buffers(context); return (jlong)context; } AUDIO_DECODER_FUNC(void, ffmpegRelease, jlong context) { if (context) { releaseContext((AVCodecContext *)context); } } AVCodec *getCodecByName(JNIEnv *env, jstringcodecName) { if (!codecName) { return NULL; } const char *codecNameChars = env->GetStringUTFChars(codecName,NULL); AVCodec *codec = avcodec_find_decoder_by_name(codecNameChars); env->ReleaseStringUTFChars(codecName, codecNameChars); return codec; } AVCodecContext *createContext(JNIEnv *env, AVCodec *codec,jbyteArrayextraData, jbooleanoutputFloat, jintrawSampleRate, jintrawChannelCount) { AVCodecContext *context = avcodec_alloc_context3(codec); if (!context) { LOGE("Failed to allocate context."); return NULL; } context->request_sample_fmt = outputFloat ? OUTPUT_FORMAT_PCM_FLOAT : OUTPUT_FORMAT_PCM_16BIT; if (extraData) { jsize size = env->GetArrayLength(extraData); context->extradata_size = size; context->extradata = (uint8_t *)av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE); if (!context->extradata) { LOGE("Failed to allocate extradata."); releaseContext(context); return NULL; } env->GetByteArrayRegion(extraData, 0, size, (jbyte *)context->extradata); } if (context->codec_id == AV_CODEC_ID_PCM_MULAW || context->codec_id == AV_CODEC_ID_PCM_ALAW) { context->sample_rate = rawSampleRate; context->channels = rawChannelCount; context->channel_layout = av_get_default_channel_layout(rawChannelCount); } context->err_recognition = AV_EF_IGNORE_ERR; int result = avcodec_open2(context, codec, NULL); if (result < 0) { logError("avcodec_open2", result); releaseContext(context); return NULL; } return context; } int decodePacket(AVCodecContext *context, AVPacket *packet, uint8_t *outputBuffer, int outputSize) { int result = 0; / / Queue input data. result = avcodec_send_packet(context, packet); if (result) { logError("avcodec_send_packet", result); return transformError(result); } / / Dequeue output data until it runs out. int outSize = 0; while (true) { AVFrame *frame = av_frame_alloc(); if (!frame) { LOGE("Failed to allocate output frame."); return AUDIO_DECODER_ERROR_INVALID_DATA; } result = avcodec_receive_frame(context, frame); if (result) { av_frame_free(&frame); if (result == AVERROR(EAGAIN)) { break; } logError("avcodec_receive_frame", result); return transformError(result); } / / Resample output. AVSampleFormatsampleFormat = context->sample_fmt; int channelCount = context->channels; int channelLayout = context->channel_layout; int sampleRate = context->sample_rate; int sampleCount = frame->nb_samples; int dataSize = av_samples_get_buffer_size(NULL, channelCount,sampleCount, sampleFormat, 1); SwrContext *resampleContext; if (context->opaque) { resampleContext = (SwrContext *)context->opaque; } else { resampleContext = swr_alloc(); av_opt_set_int(resampleContext, "in_channel_layout",channelLayout, 0); av_opt_set_int(resampleContext, "out_channel_layout",channelLayout, 0); av_opt_set_int(resampleContext, "in_sample_rate",sampleRate, 0); av_opt_set_int(resampleContext, "out_sample_rate",sampleRate, 0); av_opt_set_int(resampleContext, "in_sample_fmt",sampleFormat, 0); / / The output format is always the requested format. av_opt_set_int(resampleContext, "out_sample_fmt", context->request_sample_fmt, 0); result = swr_init(resampleContext); if (result < 0) { logError("swr_init", result); av_frame_free(&frame); return transformError(result); } context->opaque = resampleContext; } int inSampleSize = av_get_bytes_per_sample(sampleFormat); int outSampleSize = av_get_bytes_per_sample(context->request_sample_fmt); int outSamples = swr_get_out_samples(resampleContext,sampleCount); int bufferOutSize = outSampleSize * channelCount * outSamples; if (outSize + bufferOutSize>outputSize) { LOGE("Output buffer size (%d) too small for output data (%d).", outputSize, outSize + bufferOutSize); av_frame_free(&frame); return AUDIO_DECODER_ERROR_INVALID_DATA; } result = swr_convert(resampleContext, &outputBuffer,bufferOutSize, (const uint8_t **)frame->data, frame->nb_samples); av_frame_free(&frame); if (result < 0) { logError("swr_convert", result); return AUDIO_DECODER_ERROR_INVALID_DATA; } int available = swr_get_out_samples(resampleContext, 0); if (available != 0) { LOGE("Expected no samples remaining after resampling, butfound %d.", available); return AUDIO_DECODER_ERROR_INVALID_DATA; } outputBuffer += bufferOutSize; outSize += bufferOutSize; } return outSize; } int transformError(int errorNumber) { return errorNumber == AVERROR_INVALIDDATA ? AUDIO_DECODER_ERROR_INVALID_DATA : AUDIO_DECODER_ERROR_OTHER; } void logError(const char *functionName, int errorNumber) { char *buffer = (char *)malloc(ERROR_STRING_BUFFER_LENGTH * sizeof(char)); av_strerror(errorNumber, buffer, ERROR_STRING_BUFFER_LENGTH); LOGE("Error in %s: %s", functionName, buffer); free(buffer); } void releaseContext(AVCodecContext *context) { if (!context) { return; } SwrContext *swrContext; if ((swrContext = (SwrContext *)context->opaque)) { swr_free(&swrContext); context->opaque = NULL; } avcodec_free_context(&context); } Further, in step 5, after the media player application loads the decoding library, it plays media files according to the playlist and monitors whether any media files in the storage space have changed. If the media files in the playlist have changed, the sub-step of updating the summary list and the playlist is as follows: The media player application creates a background startup service monitoring mechanism by listening to system broadcasts. It obtains information about whether the media files in the playlist have changed through these broadcasts. If the media files in the playlist have changed, it retrieves the changed media files, reads their metadata, and updates the summary list and the playlist.

[0051] Preferably, the method determines whether a media file has been modified / replaced by comparing whether the checksum of the same media file has changed. If the media file has been replaced, the metadata of the corresponding media file in the summary list and the playlist is updated. If a media file has been deleted / cannot be read, it is removed from the summary list and the playlist, or a prompt is displayed in the media player application interface.

[0052] Preferably, registering Android broadcast receivers allows you to check if the media file has changed. Preferably, all undefined variables in this invention, if not explicitly defined, can be manually set thresholds.

[0053] like Figure 2 The diagram shown is a schematic block diagram of a multi-format audio data management system based on local storage, according to an embodiment of the present invention.

[0054] This invention provides a multi-format audio data management system based on local storage, the system comprising: System interaction module: used for runtime environment checks to obtain a runtime environment summary, loading dynamic .so libraries, and receiving system broadcasts to obtain changes in media files; Media file scanning module: The media file scanning module is used to scan the storage space of the media player and generate a file list, summary list, and playlist; Media file playback module: used to play the corresponding media files according to the playlist; Playlist update module: When the system interaction module detects a change in any media file in the playlist, it updates the file list, the summary list, and the playlist.

[0055] The aforementioned multi-format audio data management system based on local storage can run on computing devices such as desktop computers, laptops, PDAs, and cloud servers. The system that can run this multi-format audio data management system based on local storage may include, but is not limited to, processors and memory. Those skilled in the art will understand that the examples described are merely illustrations of a multi-format audio data management system based on local storage and do not constitute a limitation on such a system. It may include more or fewer components, or a combination of certain components, or different components. For example, the multi-format audio data management system based on local storage may also include input / output devices, network access devices, buses, etc.

[0056] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. This processor is the control center of the operating system of the local storage-based multi-format audio data management system, connecting various parts of the operating system through various interfaces and lines.

[0057] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the local storage-based multi-format audio data management system by running or executing the computer programs and / or modules stored in the memory, and by calling the data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory may include random access memory (RAM), and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0058] Although the invention has been described in considerable detail and particularly with regard to several of the described embodiments, it is not intended to limit itself to any of these details or embodiments or any particular embodiment, thereby effectively covering the intended scope of the invention. Furthermore, the invention has been described above with respect to embodiments foreseeable by the inventors in order to provide a useful description, and non-substantial modifications to the invention that have not yet been foreseen may still represent equivalent modifications.

[0059] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, illustrative uses of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0060] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the invention.

Claims

1. A method for managing multi-format audio data based on local storage, characterized in that, The method includes the following steps: Step 1: After being woken up / started, the media player application performs a runtime environment check to obtain a runtime environment summary; Step 2: The media player application searches the storage space of the media player running the media player application, searches the storage space for media files supported by the media player application, and generates a file list; Step 3: The media player application extracts the metadata of the media files based on the file list, and generates a summary list based on the extracted metadata; Step 4: The media player application loads the summary list into the media player's memory, and loads the decoding library according to the media file to be played and the runtime environment summary to generate a playlist; Step 5: After loading the decoding library, the media player application plays media files according to the playlist and monitors whether any media files in the storage space have changed. If the media files in the playlist have changed, the summary list and the playlist are updated.

2. The method for managing multi-format audio data based on local storage according to claim 1, characterized in that, In step 1, the sub-step of the media player application performing a runtime environment check to obtain a runtime environment summary after being woken up / started is as follows: After the media player application is woken up / started, it detects the current running environment, which includes the Android OS version, CPU architecture, CPU encoding and decoding capabilities, DRM support level, and SD card read / write permission acquisition status, and generates a running environment summary based on the current running environment. If the media player application does not obtain read / write permissions for the SD card, the user will be prompted on the GUI to confirm and obtain permissions. The CPU architecture is one of armeabi, armeabi-v7a, arm64-v8a, x86, RISC-V, MIPS, or MIPS64.

3. The method for managing multi-format audio data based on local storage according to claim 1, characterized in that, In step 2, the sub-step of the media player application searching the storage space of the media player running the media player application and searching the storage space for media files supported by the media player application is as follows: If the media player application obtains read / write permissions for the media player's storage space, it will iterate through the media files supported by the media player application in the media player's storage space. If the media player application cannot obtain read / write permissions for the media player's storage space, then exit the media player application. Generate a file list based on the media files; The media player application includes a built-in list of supported media file formats. The media files supported by the media player application are determined by comparing the file extensions of the media files with the built-in list of supported media file formats. Alternatively, the supported list of media file formats supported by the media player application can be determined through the runtime environment summary; or the supported list of formats supported by the media player application can be hardcoded as MP3, WMA, WAV, APE, FLAC, OGG, AAC, AC3, EC3, DD+; the file list includes the path of the media file in the storage space.

4. The method for managing multi-format audio data based on local storage according to claim 3, characterized in that, In step 3, the sub-step of the media player application extracting metadata from the media files based on the file list and generating a summary list based on the extracted metadata is as follows: The file list is loaded into the Android system cache. The media player application reads the metadata of the media files in the file list, generates a summary list based on the read metadata, and stores it in the data directory of the media player application. The metadata includes the format of the media file, the decoding library required to play the media file, file size, checksum, format, file name, artist, album, duration, and file path. The checksum is generated based on the size of the media file and one or more sub-items of the metadata.

5. The method for managing multi-format audio data based on local storage according to claim 1, characterized in that, In step 4, the media player application loads the summary list into the media player's memory, and loads the decoding library according to the media file to be played and the runtime environment summary. The sub-steps for generating the playlist are as follows: The media player application loads the summary list into the media player's memory, and loads the decoding library according to the media file selected by the user and the runtime environment summary, generates a playlist, and stores it in the data folder of the media player application; The playlist includes the path to the media file to be played and the corresponding decoding library for the media file. The decoding library is a dynamic .so library, which is provided by the media player application and stored in the jniLibs directory of the media player application. The jniLibs directory contains corresponding decoding libraries for different CPU architectures and different formats.

6. The method for managing multi-format audio data based on local storage according to claim 5, characterized in that, If the media file is in DD+ format, then set the decoding library to libHwAudio_dcvdev.so.

7. The method for managing multi-format audio data based on local storage according to claim 1, characterized in that, In step 5, after the media player application loads the decoding library, it plays media files according to the playlist and monitors whether any media files in the storage space have changed. If the media files in the playlist have changed, the sub-steps of updating the summary list and the playlist are as follows: The media player application creates a background startup service monitoring mechanism by listening to system broadcasts. It obtains information about whether the media files in the playlist have changed through these broadcasts. If the media files in the playlist have changed, it retrieves the changed media files, reads their metadata, and updates the summary list and the playlist.

8. A multi-format audio data management system based on local storage, characterized in that, The system performs the steps of the multi-format audio data management method based on local storage as described in any one of claims 1 to 7; The system includes: System interaction module: used for runtime environment checks to obtain a runtime environment summary, loading dynamic .so libraries, and receiving system broadcasts to obtain changes in media files; Media file scanning module: The media file scanning module is used to scan the storage space of the media player and generate a file list, summary list, and playlist; Media file playback module: used to play the corresponding media files according to the playlist; Playlist update module: When the system interaction module detects a change in any media file in the playlist, it updates the file list, the summary list, and the playlist.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of a multi-format audio data management method based on local storage as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: A memory on which computer programs are stored; A processor is configured to execute the computer program in the memory to implement the steps of the multi-format audio data management method based on local storage as described in any one of claims 1 to 7.

Images