android音频分析

⑴ android频谱分析怎么做

Android 音乐频谱分析，把时域上连续的信号(波形)强度转换成离散的频域信号(频谱)。
目前该 软件，没有安卓版，主要是太复杂了，大型软件很少有安卓版的。实时频谱分析仪/音频可视化功能： - 128个高品质的频段20Hz到22kHz的] - 对数频率刻度，以符合人类感知 - 低延迟高响应性 - 的帧率看到平滑的频率和幅度的动作 - 高性能的本机代码中使用OpenGL ES 2.0的参考 - FFT窗口大小2048@43/58（用于ARMv7+）帧

⑵ Android音频播放

最近需要在Android的客户端中使用PCM声音播放和录制，简单学习了一下。有不正确的地方还请指出。

首先有几个概念需要了解一下：采样频率、声道数、采样位数。

采样频率一般是sample rate， 代表的是数字化音频时每秒采样的次数。常见的有44.1KHz（CD品质）、48KHz等。

这个很好理解，单声道Mono就是声音从一个方向传出来；双声道Stereo也叫立体声，声音是从两个方向传来。通常的流行音乐中，仔细听能发现每个声道可能侧重不同的乐曲声部，比如左声道吉他，右声道钢琴，人声似乎两个声道都有，听起来就像站在中间一样。（这里没有考证，随便举例）

每一个采样都是一个数据点，采样位数是指这个数据点使用了几位来记录。AudioTrack类只支持8位和16位的PCM音频。8位就是2的8次方，即256个值；而16位则是2的16次方，有65536个值。

这个在音频的编解码中还是比较常用的。在PCM格式中，1秒钟音频的数据大小是SampleRate×Channel×Bit/8，单位是byte字节。由于PCM本身没有音频帧的概念，所以通过这个公式就能计算出任意时长音频的大小，或者得到任意大小音频的时长。如果规定1个音频帧是“每个声道256个采样”，双声道下就是512个采样，那么1帧的数据量就是256×Channel×Bit/8，同理可以推断出1秒钟有多少音频帧等等。音频帧的概念在各种编解码中各有不同，但计算公式大同小异，这里不展开。

Android中音频的播放使用的是AudioTrack类，具体用法非常简单。
首先设置buffer大小。AudioTrack播放时需要先写入buffer，如果这个buffer没有写满，那么这部分是不会播放的。所以buffer不能设置太小，这样会导致播放不连贯；而buffer也不能设置太小，这样不间断写入会消耗许多CPU资源。AudioTrack自带了getMinBufferSize方法可以给出一个最小buffer，一般用这个值就可以。getMinBufferSize方法三个参数分别是sample rate、channel和bit。

设置完buffer size就可以实例化一个AudioTrack。其中第一个参数streamType是指不同的音频流类型，包括STREAM_MUSIC、STREAM_ALARM、STREAM_VOICE_CALL、STREAM_RING等，是Android对不同音频的分类。中间三个参数很好理解，第四个是buffer size，刚刚计算出来了。最后一个参数mode有两种：MODE_STREAM和MODE_STATIC。前者是以流形式播放，后者则是一次性全部写入然后播放。

调用实例的play()方法就可以开始播放了。不过播放得要有数据吧？要填写数据就要用到write()方法。write方法中第一个参数是一个byte[]类型，是要写入的数据源，可以是从文件流中读取出来的；第二个参数offset是初始位移，即从source的哪个位置开始；第三个参数则是输入长度。

当write方法写满一个AudioTrack的buffer时，就会有声音播放出来了。
当播放完成后记得要把AudioTrack停止并释放。

⑶ android中怎么对音频数据pcm进行解码

工程代码结构较为简单：

简单说下思路，先把PCM音频数据从指定的路径文件读到内存，然后给AudioPlayer设置数据源，音频参数等，最后执行播放，暂停，停止等操作
贴上部分类代码片段：
public class AudioParam {

int mFrequency; // 采样率

int mChannel; // 声道

int mSampBit; // 采样精度

}

public interface PlayState {

public static final int MPS_UNINIT = 0; // 未就绪

public static final int MPS_PREPARE = 1; // 准备就绪(停止)

public static final int MPS_PLAYING = 2; // 播放中

public static final int MPS_PAUSE = 3; // 暂停
}

⑷ Android OpenGLES3绘图 - 音频可视化（模仿MIUI系统效果）

小米手机播放音乐时锁屏页面可以设置音频可视化效果，这是用OpenGL绘制出来的，我们来实现一下。

首先简单分析一下原理：
图形的每一行代表一个声音片段，它就是一个一维数组，按照数值大小绘制不同的高度，就形成了一条“山脉”；获取到下一个声音片段后，将它绘制到下面一行，然后画面整体向上滚动就可以了。整体类似于绘制一张游戏里常见的3D地形图。

创建一个MediaPlayer，它可以直接读取res/raw里面的音频文件，start()开始播放

Visualizer是Android SDK里面提供的音频分析工具，它可以直接获取播放的音频的波形和频谱。onWaveFormDataCapture回调方法里返回的是原始的PCM波形数组，onFftDataCapture回调方法里返回的是经过快速傅里叶方法转换后的声音频谱数组，数组的第一位是直流分量，后面是不同频率的数值。

每次获取到的是一组声音数据，将它传给Render绘制。

首先确定图形的长宽，宽度w其实是由每组音频的数组长度决定，可以由Visualizer.getCaptureSizeRange()[0]获取，这里获取的是最小的数组，也可以用Visualizer.getCaptureSizeRange()[1]获取最大的数组；长度h可以自己设置想展示多长。

绘制地形图也就是绘制w * h * 2个三角形，创建vao、vbo和ebo，由于顶点的位置都是固定的，可以在顶点着色器中用gl_VertexID获取，所以vbo里面不用传顶点数据，直接传声音数组。

由于图形是不断刷新最后一行并向上滚动的，那么需要使用一个队列，为了每一帧数据改变最小，不至于进行大量的数组复制和移动。我们 用ByteBuffer vertexBuffer模拟一个循环队列，使用一个行号int lineNum来标记队列的头部。每添加一行数据后，lineNum会加上w，这样ByteBuffer分成了两部分：lineNum * w之后的是新旧数据，之前的是旧数据 。

现在我们需要将数据从主内存（vertexBuffer）复制到GPU显存（vbo）。vertexBuffer里是一个循环队列，而vbo里面只能顺序保存（因为ebo序号是顺序的，vbo不是顺序图形就会错乱），更新vbo数据缓存的glBufferSubData方法支持设置偏移位置部分更新。那么我们 先将vertexBuffer定位到lineNum * w，将它后面的旧数据复制到vbo的前面；然后将vertexBuffer定位到0，将剩下的新数据复制到vbo的后面 。这样就保证了绘制时从上到下，从旧到新。

为了让颜色更丰富，这里用了地形图中常用的热度渐变色数组。
理论上音频数值是unsigned byte格式的，但是着色器不支持byte格式，我直接用int vPosition接收数据，然而数值范围不再是0~255了，这有点奇怪，我没有深入研究。简单测试了一下，发现取int的前8位，再进行一点比例缩放，用它去渐变色数组里取颜色，会取得较好的显示效果。

顶点着色器
shader_audio_v.glsl

将颜色传给片段着色器显示
shader_audio_f.glsl

最终效果如下图，录屏设置的码率比较低，实际上是很清晰的。

完整项目在 SurfacePaint 项目下的 opengles3 模块里的audio。

⑸ android里如何解析音频文件获取标题、专辑、文件名、艺术家

如果有的话，用WMP播放就可以看见了

⑹ 安卓系统为什么音质不好

Android 基于Linux，我们先来了解一下Linux的特点。Linux使用ALSA作为其音频架构，其全称Advanced Linux Sound Architecture，即高级Linux声音架构的意思，在2.6核心之后，ALSA成为了Linux系统默认的音频子架构。取代了之前的OSS[Open Sound System，开放式声音系统]。

ALSA并不太好理解，它首先是一个驱动库，包含了大量的声卡设备的开源驱动，并提供了核心层API与ALSA库通信，而ALSA库则是应用程序访问和操控音频硬件的中间层，这个中间层有标准接口，开发者可以无须考虑硬件差异性进行开发，它对提升开发效率是大有帮助的。ALSA可以向下兼容OSS，因为OSS已经被淘汰，其兼容的工作模式不再讨论。

这个体系被继承到了Android当中。在Android2.2[含2,2]之前，系统文件夹中能找到一个LibAudioALSA.so的文件，这就是ALSA库文件，其他应用程序调用它，与声卡设备进行指令和数据通信。Android音频架构与Linux的并无本质区别。

在桌面版本的Linux当中，为了兼容各类声卡，Linux也设置了一个SRC[Sample Rate Converter，采样频率转换]的环节，当当前采样率低于48kHz时强制SRC到48kHz输出。这个SRC环节位于ALSA的插件模块中的混音器部分。Android针对这个进行了改进。
什么是SRC？SRC即Sample Rate Converter，中文意思为采样频率转换。它被声卡爱好者所关注，大部分发烧友视SRC为音质杀手。

Android增加了一个AudioFinger，这个可以简单的理解为Android的ALSA音频子系统的标准化的插件模块，它包含了AudioMixer[混音器]、AudioResampler[重采样]等子模块，AudioResampler即我们理解的SRC，Android换了一个新名称而已。针对SRC，Android做了改进，但改进并不是以去除SRC为目的，而是修改了默认的输出频率，Android的SRC目标采样率为44.1kHz，非该值的采样率都将SRC处理。例如播放48kHz采样率的信号，输出的最终是44.1kHz，这对音质将产生负面影响。

ALSA是一个针对Linux 桌面版本设计的音频架构，它实际上是不适合智能终端设备的，起码里面大量的开源驱动代码是可以去除的，对与Android来说，这些都是废代码。从Android2.3起，启用了一个新的音频架构。它放弃了一直使用的ALSA架构，因此系统文件夹中，也不再有LibAudioALSA.so这个文件。

Android2.3起，架构已经做了修改，在针对内部代码进行了优化，去除了冗余代码，理论上让系统能变得更加高效，可以将新架构理解为一个精简的或者为智能终端设备定制的ALSA架构。遗憾的是，它同样存在SRC严重劣化的问题，通过测试可以证明。
Android 3.0专门为平板电脑设计，影音体验变得更加重要了，是不是新系统在音质方面会有新的的进步呢，测试结果依然是令人失望的。

Android系统将采样率同一为44.1kHz输出，这造成了诸多限制，它将无法实现96kHz、192kHz高清音频节目的良好回放，大量视频节目源自DVD或者蓝光盘，其采用率多为48kHz，Android设备在回放这些视频节目时，音质也将大打折扣。

理论上软件SRC可以通过更换算法来实现音质提升，但却不太现实，智能终端所采用的CPU多为ARM，ARM芯片的浮点运算力有限，而SRC需要大量的浮点运算的资源，即便有了高质量的SRC算法，其运算也是以牺牲设备性能和耗电量为代价的，实用性差。

从Android的音频架构及流程分析，可以认为，播放44.1kHz采样率的音乐节目时，不会引发SRC，音质因此可以获得保证，理论上确实如此。但它同样存在问题，不管是之前的ALSA架构还是Android2.3之后改良的架构，其驱动库都位于核心层，也就意味着音频设备厂商、用户无法象PC平台那样安装驱动来改善音质。实际测试也表明，Android设备音质普遍偏差，Soomal有大量测试可以证明。

我们再把目光投向iOS，iOS非常封闭，我们甚至无法获知其架构的具体构成，但iOS设备不存在硬件设备多样性的问题，因此要实现更好音质也会更加简单。iOS可以实现针对性的开发和改良，以实现更好的音质。实际情况也是如此，目前为止，还没有一款Android设备的音质可以媲美任意一款iOS设备，这种差距，我们认为不是来自硬件，而是操作系统。

Android音频架构的局限性也使得其难以成为优质的影音平台，如果你希望设计一款基于Android的高清影音播放器，那么首先需要做的不是设计硬件，而是去修改现有架构的不足，或者干脆设计一个专用的架构来取代Android的通用架构。从源代码分析，Android和原生的Linux底层能支持各种采样率，开源也使得其具有改造基础，因此，在技术实力强劲的公司手里，Android也可以乌鸡变凤凰。

⑺ Android音视频三：AudioFlinger和HAL

先看看和Audio有关的hal文件 具体路径/hardware/interfaces/audio/文件夹下（这里看的是6.0的）

在分析AudioFlinger的时候留下的和HAL有关的三个地方

DevicesFactoryHalInterface.cpp

FactoryHalHidl.cpp

DevicesFactoryHalHybrid.cpp

DevicesFactoryHalHidl.cpp

经过上面的步骤已经可以调用到IDeviceFactory的方法了，所以执行方法也就是走流程的事情

DevicesFactoryHalHybrid.cpp

DevicesFactoryHalHidl.cpp

DeviceFacotry.cpp

调用流程：AudioFlinger -> AudioHwDevice -> AudioStreamOut -> DeviceHalHidl -> Device.cpp -> audio.h 得到结果：拿到输出流后，包装成IStreamOut，在向上一层层包装

AudioFlinger.cpp

AudioHwDevice.cpp

AudioStreamOut.cpp

DeviceHalHidl.cpp

⑻ android里如何解析音频文件获取标题、专辑、文件名、艺术家

把文件放在res/raw下，程序运行时把它释放到指定目录，代码如下：（供楼主参考）

private final String DATABASE_PATH = android.os.Environment.getExternalStorageDirectory().getAbsolutePath() + "/db_exam";
private final String DATABASE_FILENAME = "tel.db";

public void extractDBFileFromRes(){
try {
String dbFileName = DATABASE_PATH + "/" + DATABASE_FILENAME;
File dir = new File(DATABASE_PATH);
if (!dir.exists()){
dir.mkdir();
Log.i("SQLite", "dir made:" + DATABASE_PATH);
} else {
Log.i("SQLite", "dir exist:" + DATABASE_PATH);
}

try {
//如果数据库已经在SD卡的目录下存在，那么不需要重新创建，否则创建文件，并拷贝/res/raw下面的数据库文件
if (!(new File(dbFileName).exists())){
Log.i("SQLite", dbFileName + ":file not exist");
//res/raw数据库作为输出流
InputStream inputStream = this.getResources().openRawResource(R.raw.tel);
//测试
int size = inputStream.available();
Log.i("SQLite", "DATABASE_SIZE:" + 1);
Log.i("SQLite", "count:" + 0);
//用于存放数据库信息的数据流
FileOutputStream fileOutputStream = new FileOutputStream(dbFileName);
byte[] buffer = new byte[8192];
int count = 0;
Log.i("SQLite", "count:" + count);

//把数据写入SD卡目录下
while ((count = inputStream.read(buffer)) > 0 ) {
fileOutputStream.write(buffer, 0, count);
}
fileOutputStream.flush();
fileOutputStream.close();
inputStream.close();
}

} catch (FileNotFoundException e) {
Log.e("Database", "File not found");
e.printStackTrace();
}
} catch (IOException e) {
Log.e("Database", "IO exception");
e.printStackTrace();
}

}

⑼ Android -- 音视频基础知识

帧，是视频的一个基本概念，表示一张画面，如上面的翻页动画书中的一页，就是一帧。一个视频就是由许许多多帧组成的。

帧率，即单位时间内帧的数量，单位为：帧/秒 或fps（frames per second）。一秒内包含多少张图片，图片越多，画面越顺滑，过渡越自然。 帧率的一般以下几个典型值：

24/25 fps：1秒 24/25 帧，一般的电影帧率。

30/60 fps：1秒 30/60 帧，游戏的帧率，30帧可以接受，60帧会感觉更加流畅逼真。

85 fps以上人眼基本无法察觉出来了，所以更高的帧率在视频里没有太大意义。

这里我们只讲常用到的两种色彩空间。

RGB的颜色模式应该是我们最熟悉的一种，在现在的电子设备中应用广泛。通过R G B三种基础色，可以混合出所有的颜色。

这里着重讲一下YUV，这种色彩空间并不是我们熟悉的。这是一种亮度与色度分离的色彩格式。

早期的电视都是黑白的，即只有亮度值，即Y。有了彩色电视以后，加入了UV两种色度，形成现在的YUV，也叫YCbCr。

Y：亮度，就是灰度值。除了表示亮度信号外，还含有较多的绿色通道量。

U：蓝色通道与亮度的差值。

V：红色通道与亮度的差值。

音频数据的承载方式最常用的是 脉冲编码调制 ，即 PCM 。

在自然界中，声音是连续不断的，是一种模拟信号，那怎样才能把声音保存下来呢？那就是把声音数字化，即转换为数字信号。

我们知道声音是一种波，有自己的振幅和频率，那么要保存声音，就要保存声音在各个时间点上的振幅。

而数字信号并不能连续保存所有时间点的振幅，事实上，并不需要保存连续的信号，就可以还原到人耳可接受的声音。

根据奈奎斯特采样定理：为了不失真地恢复模拟信号，采样频率应该不小于模拟信号频谱中最高频率的2倍。

根据以上分析，PCM的采集步骤分为以下步骤：

采样率，即采样的频率。

上面提到，采样率要大于原声波频率的2倍，人耳能听到的最高频率为20kHz，所以为了满足人耳的听觉要求，采样率至少为40kHz，通常为44.1kHz，更高的通常为48kHz。

采样位数，涉及到上面提到的振幅量化。波形振幅在模拟信号上也是连续的样本值，而在数字信号中，信号一般是不连续的，所以模拟信号量化以后，只能取一个近似的整数值，为了记录这些振幅值，采样器会采用一个固定的位数来记录这些振幅值，通常有8位、16位、32位。

位数越多，记录的值越准确，还原度越高。

最后就是编码了。由于数字信号是由0，1组成的，因此，需要将幅度值转换为一系列0和1进行存储，也就是编码，最后得到的数据就是数字信号：一串0和1组成的数据。

整个过程如下：

声道数，是指支持能不同发声（注意是不同声音）的音响的个数。 单声道：1个声道
双声道：2个声道
立体声道：默认为2个声道
立体声道（4声道）：4个声道

码率，是指一个数据流中每秒钟能通过的信息量，单位bps（bit per second）

码率 = 采样率 * 采样位数 * 声道数

这里的编码和上面音频中提到的编码不是同个概念，而是指压缩编码。

我们知道，在计算机的世界中，一切都是0和1组成的，音频和视频数据也不例外。由于音视频的数据量庞大，如果按照裸流数据存储的话，那将需要耗费非常大的存储空间，也不利于传送。而音视频中，其实包含了大量0和1的重复数据，因此可以通过一定的算法来压缩这些0和1的数据。

特别在视频中，由于画面是逐渐过渡的，因此整个视频中，包含了大量画面/像素的重复，这正好提供了非常大的压缩空间。

因此，编码可以大大减小音视频数据的大小，让音视频更容易存储和传送。

视频编码格式有很多，比如H26x系列和MPEG系列的编码，这些编码格式都是为了适应时代发展而出现的。

其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）国际电传视讯联盟主导

MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的组织）主导。

当然，他们也有联合制定的编码标准，那就是现在主流的编码格式H264，当然还有下一代更先进的压缩编码标准H265。

H264是目前最主流的视频编码标准，所以我们后续的文章中主要以该编码格式为基准。

H264由ITU和MPEG共同定制，属于MPEG-4第十部分内容。

我们已经知道，视频是由一帧一帧画面构成的，但是在视频的数据中，并不是真正按照一帧一帧原始数据保存下来的（如果这样，压缩编码就没有意义了）。

H264会根据一段时间内，画面的变化情况，选取一帧画面作为完整编码，下一帧只记录与上一帧完整数据的差别，是一个动态压缩的过程。

在H264中，三种类型的帧数据分别为

I帧：帧内编码帧。就是一个完整帧。

P帧：前向预测编码帧。是一个非完整帧，通过参考前面的I帧或P帧生成。

B帧：双向预测内插编码帧。参考前后图像帧编码生成。B帧依赖其前最近的一个I帧或P帧及其后最近的一个P帧。

全称：Group of picture。指一组变化不大的视频帧。

GOP的第一帧成为关键帧：IDR

IDR都是I帧，可以防止一帧解码出错，导致后面所有帧解码出错的问题。当解码器在解码到IDR的时候，会将之前的参考帧清空，重新开始一个新的序列，这样，即便前面一帧解码出现重大错误，也不会蔓延到后面的数据中。

DTS全称：Decoding Time Stamp。标示读入内存中数据流在什么时候开始送入解码器中进行解码。也就是解码顺序的时间戳。

PTS全称：Presentation Time Stamp。用于标示解码后的视频帧什么时候被显示出来。

前面我们介绍了RGB和YUV两种图像色彩空间。H264采用的是YUV。

YUV存储方式分为两大类：planar 和 packed。

planar如下：

packed如下：

上面说过，由于人眼对色度敏感度低，所以可以通过省略一些色度信息，即亮度共用一些色度信息，进而节省存储空间。因此，planar又区分了以下几种格式：YUV444、 YUV422、YUV420。

YUV 4:4:4采样，每一个Y对应一组UV分量。

YUV 4:2:2采样，每两个Y共用一组UV分量。

YUV 4:2:0采样，每四个Y共用一组UV分量。

其中，最常用的就是YUV420。

YUV420属于planar存储方式，但是又分两种类型：

YUV420P：三平面存储。数据组成为YYYYYYYYUUVV（如I420）或YYYYYYYYVVUU（如YV12）。

YUV420SP：两平面存储。分为两种类型YYYYYYYYUVUV（如NV12）或YYYYYYYYVUVU（如NV21）

原始的PCM音频数据也是非常大的数据量，因此也需要对其进行压缩编码。

和视频编码一样，音频也有许多的编码格式，如：WAV、MP3、WMA、APE、FLAC等等，音乐发烧友应该对这些格式非常熟悉，特别是后两种无损压缩格式。

但是，我们今天的主角不是他们，而是另外一个叫AAC的压缩格式。

AAC是新一代的音频有损压缩技术，一种高压缩比的音频压缩算法。在MP4视频中的音频数据，大多数时候都是采用AAC压缩格式。

AAC格式主要分为两种：ADIF、ADTS。

ADIF：Audio Data Interchange Format。音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。这种格式常用在磁盘文件中。

ADTS：Audio Data Transport Stream。音频数据传输流。这种格式的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。它的特征类似于mp3数据流格式。

ADIF数据格式：

ADTS 一帧 数据格式（中间部分，左右省略号为前后数据帧）：

AAC内部结构也不再赘述，可以参考AAC 文件解析及解码流程

细心的读者可能已经发现，前面我们介绍的各种音视频的编码格式，没有一种是我们平时使用到的视频格式，比如：mp4、rmvb、avi、mkv、mov...

没错，这些我们熟悉的视频格式，其实是包裹了音视频编码数据的容器，用来把以特定编码标准编码的视频流和音频流混在一起，成为一个文件。

例如：mp4支持H264、H265等视频编码和AAC、MP3等音频编码。

我们在一些播放器中会看到，有硬解码和软解码两种播放形式给我们选择，但是我们大部分时候并不能感觉出他们的区别，对于普通用户来说，只要能播放就行了。

那么他们内部究竟有什么区别呢？

在手机或者PC上，都会有CPU、GPU或者解码器等硬件。通常，我们的计算都是在CPU上进行的，也就是我们软件的执行芯片，而GPU主要负责画面的显示（是一种硬件加速）。

所谓软解码，就是指利用CPU的计算能力来解码，通常如果CPU的能力不是很强的时候，一则解码速度会比较慢，二则手机可能出现发热现象。但是，由于使用统一的算法，兼容性会很好。

硬解码，指的是利用手机上专门的解码芯片来加速解码。通常硬解码的解码速度会快很多，但是由于硬解码由各个厂家实现，质量参差不齐，非常容易出现兼容性问题。

MediaCodec 是Android 4.1(api 16)版本引入的编解码接口，是所有想在Android上开发音视频的开发人员绕不开的坑。

由于Android碎片化严重，虽然经过多年的发展，Android硬解已经有了很大改观，但实际上各个厂家实现不同， 还是会有一些意想不到的坑。

相对于FFmpeg，Android原生硬解码还是相对容易入门一些，所以接下来，我将会从MediaCodec入手，讲解如何实现视频的编解码，以及引入OpenGL实现对视频的编辑，最后才引入FFmpeg来实现软解，算是一个比较常规的音视频开发入门流程吧。

⑽ android中可以提取视频文件中的音频吗

怎么样才可以将视频中的一些音频提取出来呢？把视频中有趣的音频提取出来有难度吗？其实操作非常的简单哦！不管是视频音频或者是音乐音频都是可以提取的，那么接下来就好好和你们说说如何提取音频的吧！具体操作步骤如下：
第一步提取视频音频之前，需要安装一款迅捷音频转换器
第二步打开后你们就会看到它的整体界面，在界面中会有一些功能，这些功能在我们的日常工作中都会遇到，今天我们需要点击的就是音频提取，接着添加文件或者添加文件夹。
第三步文件添加进去之后，提取音频的步骤来了，大家会看到添加片段指南，怎么添加呢？拉动上方的进度条就可以添加了，这个时候你们所看到的当前时间点显示的就是你添加音频的时间，然后点击确定。
第四步在我们点击确定之后，我们就要来到界面的地步，看到文件输出目录点击文件夹就可以选择保存的位置了，当我们的保存位置设置好之后，最后点击开始提取。
第五步等待一会之后，界面你提取的音乐片段都会显示个小对号，这个时候你们的提取已经完成了，然后在你们的保存的文件中就可以打开了。