基于Qt的音频管理系统的设计与实现
毕业设计（论文）原创性声明和使用授权说明
原创性声明
本人郑重承诺：所呈交的毕业设计（论文），是我个人在指导教师的指导下进行的研究工作及取得的成果。尽我所知，除文中特别加以标注和致谢的地方外，不包含其他人或组织已经发表或公布过的研究成果，也不包含我为获得 及其它教育机构的学位或学历而使用过的材料。对本研究提供过帮助和做出过贡献的个人或集体，均已在文中作了明确的说明并表示了谢意。
作 者 签 名： 日 期：
指导教师签名： 日 期：
使用授权说明
本人完全了解 大学关于收集、保存、使用毕业设计（论文）的规定，即：按照学校要求提交毕业设计（论文）的印刷本和电子版本；学校有权保存毕业设计（论文）的印刷本和电子版，并提供目录检索与阅览服务；学校可以采用影印、缩印、数字化或其它复制手段保存论文；在不以赢利为目的前提下，学校可以公布论文的部分或全部内容。
作者签名： 日 期：
学位论文原创性声明
本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所取得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写的成果作品。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律后果由本人承担。
作者签名：
日期： 年 月 日
学位论文版权使用授权书
本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权 大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。
涉密论文按学校规定处理。
作者签名：
日期： 年 月 日
导师签名： 日期： 年 月 日
注 意 事 项
1.设计（论文）的内容包括：
1）封面（按教务处制定的标准封面格式制作）
2）原创性声明
3）中文摘要（300字左右）、关键词
4）外文摘要、关键词
5）目次页（附件不统一编入）
6）论文主体部分：引言（或绪论）、正文、结论
7）参考文献
8）致谢
9）附录（对论文支持必要时）
2.论文字数要求：理工类设计（论文）正文字数不少于1万字（不包括图纸、程序清单等），文科类论文正文字数不少于1.2万字。
3.附件包括：任务书、开
题
快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题
报告、外文译文、译文原文（复印件）。
4.文字、图表要求：
1）文字通顺，语言流畅，书写字迹工整，打印字体及大小符合要求，无错别字，不准请他人代写
2）工程设计类题目的图纸，要求部分用尺规绘制，部分用计算机绘制，所有图纸应符合国家技术标准
规范
编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载
。图表整洁，布局合理，文字注释必须使用工程字书写，不准用徒手画
3）毕业论文须用A4单面打印，论文50页以上的双面打印
4）图表应绘制于无格子的页面上
5）软件工程类课题应有程序清单，并提供电子文档
5.装订顺序
1）设计（论文）
2）附件：按照任务书、开题报告、外文译文、译文原文（复印件）次序装订
指导教师评阅书
指导教师评价：
一、撰写（设计）过程
1、学生在论文（设计）过程中的治学态度、工作精神
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、学生掌握专业知识、技能的扎实程度
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、学生综合运用所学知识和专业技能分析和解决问题的能力
□ 优 □ 良 □ 中 □ 及格 □ 不及格
4、研究方法的科学性；技术线路的可行性；设计
方案
气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载
的合理性
□ 优 □ 良 □ 中 □ 及格 □ 不及格
5、完成毕业论文（设计）期间的出勤情况
□ 优 □ 良 □ 中 □ 及格 □ 不及格
二、论文（设计）质量
1、论文（设计）的整体结构是否符合撰写规范？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、是否完成指定的论文（设计）任务（包括装订及附件）？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
三、论文（设计）水平
1、论文（设计）的理论意义或对解决实际问题的指导意义
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、论文的观念是否有新意？设计是否有创意？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、论文（设计说明书）所体现的整体水平
□ 优 □ 良 □ 中 □ 及格 □ 不及格
建议成绩：□ 优 □ 良 □ 中 □ 及格 □ 不及格
（在所选等级前的□内画“√”）
指导教师： （签名） 单位： （盖章）
年 月 日
评阅教师评阅书
评阅教师评价：
一、论文（设计）质量
1、论文（设计）的整体结构是否符合撰写规范？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、是否完成指定的论文（设计）任务（包括装订及附件）？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
二、论文（设计）水平
1、论文（设计）的理论意义或对解决实际问题的指导意义
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、论文的观念是否有新意？设计是否有创意？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、论文（设计说明书）所体现的整体水平
□ 优 □ 良 □ 中 □ 及格 □ 不及格
建议成绩：□ 优 □ 良 □ 中 □ 及格 □ 不及格
（在所选等级前的□内画“√”）
评阅教师： （签名） 单位： （盖章）
年 月 日
教研室（或答辩小组）及教学系意见
教研室（或答辩小组）评价：
一、答辩过程
1、毕业论文（设计）的基本要点和见解的叙述情况
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、对答辩问题的反应、理解、表达情况
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、学生答辩过程中的精神状态
□ 优 □ 良 □ 中 □ 及格 □ 不及格
二、论文（设计）质量
1、论文（设计）的整体结构是否符合撰写规范？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、是否完成指定的论文（设计）任务（包括装订及附件）？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
三、论文（设计）水平
1、论文（设计）的理论意义或对解决实际问题的指导意义
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、论文的观念是否有新意？设计是否有创意？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、论文（设计说明书）所体现的整体水平
□ 优 □ 良 □ 中 □ 及格 □ 不及格
评定成绩：□ 优 □ 良 □ 中 □ 及格 □ 不及格
教研室主任（或答辩小组组长）： （签名）
年 月 日
教学系意见：
系主任： （签名）
年 月 日
摘要
随着互联网的的发展，PC机已经不能满足终端用户对音频的需要。虽然目前有各种各样的计算机操作系统，如WINDOWS，LINUX,UNIX,MAC OS等以及各种移动开发平台，如Android，BlackBerry OS，IOS，Windows Mobile，Windows Phone，Palm等，不同的操作系统需要不同的系统软件来开发对应的应用程序。同样的功能，却要开发多次，这给程序员带来了冗余的工作量。
本文以Qt为基础，对音频管理系统的实际设计情况进行了需求分析，利用软件工程的开发流程及面向对象的思想，构建了音频管理系统的总体框架，为最终音频管理系统的实现提供了理论依据。
测试结果表明，基于Qt的音频管理系统可以在Win7的Qt5.2中运行，也可以在ubuntu的Qt5.2中运行，代码只需做微小的调整，减轻程序员的代码量，节省开发成本，为未来的开发提供一个重要的参考。
关键词 Qt；音频管理系统；设计；实现
Design and implementation of audio management system based on Qt
Abstract
With the development of the Internet,the PC has been unable to meet the needs of the audio terminal user.Despite various of computer operating system,such as WINDOWS,LINUX,UNIX,MACOS etc,and various of mobile development platform,such as Android,BlackBerry,OS,IOS,WindowsMobile,Windows Phone,Palm etc,different operating systems require different software systems to develop the corresponding application .The same function needs to develop several times,which brings redundant work for the programmer.
This paper,based on the Qt,carrying on the demand analysis of the actual design of the audio management system,using the development process of software engineering and object-oriented idea,constructing the general framework of audio management system,and provides a theoretical basis for the implementation of the final audio management system finally.
The test results show that Qt audio management system can run in Win7 based on the Qt5.2 and it can also run on ubuntu Qt5.2,the code only minor adjustments,reducing the amount of code programmers,saving development costs,providing an important reference for future development.
Key words Qt;audio management system;design; implementation
目 录
i
摘要
ii
Abstract
1
1 绪论
1
1.1 开发背景
1
1.2 系统目标
1
1.3 基于Qt程序的音频管理系统的设计的必要性
3
2 关键技术介绍
3
2.1 音频编码的简单概念
3
2.1.1 采样率和采样大小
3
2.1.2 有损和无损
3
2.1.3 音频压缩技术
3
2.1.4 频率和采样率
4
2.1.5 流特征
4
2.2 音频编码
4
2.2.1 PCM编码
4
2.2.2 WAV
4
2.2.3 MP3
5
2.2.4 OGG编码
5
2.2.5 MP3PRO编码
5
2.2.6 ACC格式
5
2.3 音频解析
5
2.3.1 MP3文件解析
7
2.3.2 WMA文件解析
8
2.3.3 OGG文件的解析
8
2.4 Qt的事件模型
9
2.4.1 事件的概念
9
2.4.2 事件的创建
9
2.4.3 事件的交付
9
2.4.4 事件循环模型
10
2.4.5 自定义事件
10
2.5 Qt核心机制信号与槽
10
2.5.1 信号
11
2.5.2 槽
11
2.5.3 信号与槽的关联
12
3 需求分析
12
3.1 需求概述
12
3.2 系统用例图
13
3.3 系统关键领域类
14
4 系统设计
14
4.1 系统介绍
14
4.2 主要功能
14
4.3 系统总体模块
14
4.3.1 系统总体模块介绍
15
4.3.2 系统层次图
15
4.4 系统界面模块介绍
15
4.4.1 主页面
16
4.4.2 以演唱者分类，显示演唱者所对应的歌曲名
16
4.4.3 以专辑名称分类，显示该专辑所对应的歌曲名
17
4.4.4 播放列表
17
4.4.5 播放控制相关按钮
17
4.4.6 播放进度条
17
4.4.7 打开按钮
17
4.5 系统功能模块划分
18
4.5.1 音频文件管理
18
4.5.2 播放控制
19
4.5.3 播放列表
19
4.6 系统开发环境
20
5 系统实现
20
5.1 树形结构显示
20
5.1.1 主要相关代码及说明
22
5.1.2 关键技术应用中问题的解决
22
5.2 播放列表
22
5.2.1 主要相关代码及说明
26
5.2.2 功能实现
26
5.3 读取MP3音频文件
26
5.3.1 主要相关代码
29
5.3.2 写代码时的思路依据
29
5.4 播放控制
29
5.4.1 主要相关功能的部分代码
34
5.4.2 媒体对象状态的简单介绍
34
5.5 播放进度条
34
5.5.1 主要相关功能的部分代码
37
6 系统测试
37
6.1 测试的意义
37
6.2 测试方法
37
6.3 测试过程
38
6.4 单元测试
38
6.5 测试总结
40
参考文献
41
致谢
42
外文原文
55
外文翻译
1 绪论
1.1 开发背景
Qt是1991年奇趣科技（Trolltech）开发的一个跨平台的C++图形用户界面应用程序框架[3,9]。它提供给应用程序开发者建立艺术级的图形用户界面所需的所用功能。Qt很容易扩展，并且允许真正地组件编程。2012年，Qt被Digia收购，之后发布Qt5.1、5.2版本，提供Qt for Android(Alpha) 、Qt for IOS 。Qt的优势在于，良好的可移植性，可支持大多数操作系统，如 Microsoft Windows 7， Linux， Solaris， SunOS， HP-UX， Digital UNIX (OSF/1， Tru64)， Irix， FreeBSD， BSD/OS， SCO， AIX， OS390，QNX 等等 ； 面向对象，Qt良好的封装机制使得Qt模块化程度非常高，代码可重用性较好，很方便用户开发丰富的API,Qt包含250个以上的C++类，并且有相应的帮助文档；支持2D 3D图形渲染，支持XML。Qt针对嵌入式环境推出了Qt Embeeded产品，Qt Embedded具有跨平台的特点，省掉了不少移植软件的功夫，用模块化设计，有弹性，Qt Embedded 最小可以缩到800KB左右，最多可以长到3MB（for Intel x86），使得Qt Embedded 更适合在嵌入式环境下生存[1,5-8,10-11]。
基于Qt跨平台的图形用户界面应用程序框架，用的是C++开发语言。C++语言简洁灵活，运算符的数据结构丰富、具有结构化控制语句、程序执行效率高，而且同时具有高级语言与汇编语言的优点，与其它语言相比，C语言具有可以直接访问物理地址的优点，与汇编语言相比又具有良好的可读性的可移植性。总得来说，C++语言的主要特点表现在两个方面，一是尽量兼容C,二是支持面向对象的方法。它操持了C的简洁、高效的接近汇编语言等特点，对C的类型系统进行了改革的扩充，因此C++比C更安全，C++的编译系统能检查出更多的类型错误。另外，由于C语言的广泛使用，因而极大的促进了C++的普及和推广。
C++语言最有意义的方面是支持面向对象的特征。虽然与C的兼容使得C++具有双重特点，但他在概念上完全与C不同，更具面向对象的特征。
智能家居等将是一个发展的趋势，嵌入式产品也必将走入千家万户。而目前PC机的音频管理软件占用的磁盘空间以及内存较大所以基于Qt的音频管理系统的设计与实现有很重要的意义。基于这种形式的把握，也基于对这种技术的学习与理解，我选择了这个课题。对音频解码技术进行研究，有助于理解其内在的原理，能够帮助我们更好的实现代码功能。
1.2 系统目标
系统开发的总任务是设计并实现一个音频管理系统。
通过本系统可以添加音频文件，以演唱者管理音频文件，以专辑管理音频文件[2,4]。你可以有一个播放列表，方便用户知道系统中有哪些音乐文件。当然了有播放列表，就要有播放功能。选中歌曲，用户可以点击播放按钮，播放音乐文件。当然有相应的控制功能，上一曲，下一曲。基本的音量控制，音量的高低调节，静音功能。
1.3 基于Qt程序的音频管理系统的设计的必要性
随着计算机技术、电子技术和通信技术的迅猛发展，嵌入式系统已经成为最热门、最有前途的IT应用领域之一，成为通讯和消费产品的共同发展方向。它广泛应用于人们在工作生活的各个方面，几乎包括了所有的电器设备。在嵌入式技术快速发展的同时，嵌入式音频设备已然成为当今人类生活中的热点。对于这些音乐文件的管理也将成为程序员考虑的重点。各种设备中的操作系统的种类不同，程序员在开发的时候总是要做重复的工作，不能把工作的重点放在设计上。基于Qt的平台正好给大家提供了一个这样的平台。代码不需要太多的改动，就可以运行在各种操作系统上。而且Qt是基于模块的设计思想，只需要加载你所需要的模块，符合嵌入式定制性强，模块简单的特点。所以基于Qt的音频管理系统非常的设计与实现非常必要。
本系统主要基于Qt跨平台的图形用户界面应用程序框架，用的是C++开发语言，当前的计算机硬件配置也完全能满足开发的需求，因此在技术上是绝对可行的。软件方面：由于目前单机模式相对发展成熟，故软件的开发平台成熟可行,它们速度快、容量大、可靠性能高、价格低，完全能满足系统的需求。
2 关键技术介绍
2.1 音频编码的简单概念
2.1.1 采样率和采样大小
声音其实是一种能量波，因此也有频率和振幅的特征，频率对应于时间轴线，振幅对应于电平轴线。波是无限光滑的，弦线可以看成由无数点组成，由于存储空间是相对有限的，数字编码过程中，必须对弦线的点进行采样。采样的过程就是抽取某点的频率值，很显然，在一秒中内抽取的点越多，获取得频率信息更丰富，为了复原波形，一次振动中，必须有2个点的采样，人耳能够感觉到的最高频率为20kHz，因此要满足人耳的听觉要求，则需要至少每秒进行40k次采样，用40kHz表达，这个40kHz就是采样率。采样率和采样大小的值越大，记录的波形更接近原始信号。
2.1.2 有损和无损
根据采样率和采样大小可以得知，相对自然界的信号，音频编码最多只能做到无限接近，至少目前的技术只能这样了，相对自然界的信号，任何数字音频编码方案都是有损的，因为无法完全还原。在计算机应用中，能够达到最高保真水平的就是PCM编码，被广泛用于素材保存及音乐欣赏，CD、DVD以及我们常见的WAV文件中均有应用。因此，PCM约定俗成了无损编码，因为PCM代表了数字音频中最佳的保真水准，并不意味着PCM就能够确保信号绝对保真，PCM也只能做到最大程度的无限接近。我们而习惯性的把MP3列入有损音频编码范畴，是相对PCM编码的。
2.1.3 音频压缩技术
PCM音频流的码率，采样率值×采样大小值×声道数 bps。一个采样率为44.1KHz，采样大小为16bit，双声道的PCM编码的WAV文件，它的数据速率则为 44.1K×16×2 =1411.2 Kbps。我们常说128K的MP3，对应的WAV的参数，就是这个1411.2 Kbps，这个参数也被称为数据带宽，它和ADSL中的带宽是一个概念。将码率除以8,就可以得到这个WAV的数据速率，即176.4KB/s。这表示存储一秒钟采样率为44.1KHz，采样大小为16bit，双声道的PCM编码的音频信号，需要176.4KB的空间，1分钟则约为10.34M，这对大部分用户是不可接受的，尤其是喜欢在电脑上听音乐的朋友，要降低磁盘占用，只有2种方法，降低采样指标或者压缩。降低指标是不可取的，各种音频压缩编码所达到的音质和压缩比都不一样。
2.1.4 频率和采样率
采样率表示了每秒对原始信号采样的次数，我们常见到的音频文件采样率多为44.1KHz，假设我们有2段正弦波信号，分别为20Hz和20KHz，长度均为一秒钟，以对应我们能听到的最低频和最高频，分别对这两段信号进行40KHz的采样，结果是：20Hz的信号每次振动被采样了40K/20=2000次，而20K的信号每次振动只有2次采样。显然，在相同的采样率下，记录低频的信息远比高频的详细。这也是CD数码声不够真实的原因，CD的44.1KHz采样也无法保证高频信号被较好记录。要较好的记录高频信号，看来需要更高的采样率，在捕捉CD音轨的时候使用48KHz的采样率，这是不可取的！这其实对音质没有任何好处，对抓轨软件来说，保持和CD提供的44.1KHz一样的采样率才是最佳音质的保证之一，而不是去提高它。较高的采样率只有相对模拟信号的时候才有用，如果被采样的信号是数字的，不要去尝试提高采样率。
2.1.5 流特征
随着网络的发展，人们对在线收听音乐提出了要求，因此也要求音频文件能够一边读一边播放，而不需要把这个文件全部读出后然后回放，这样就可以做到不用下载就可以实现收听了。也可以做到一边编码一边播放，正是这种特征，可以实现在线的直播，架设自己的数字广播电台成为了现实。
2.2 音频编码
2.2.1 PCM编码
PCM 脉冲编码调制是Pulse Code Modulation的缩写。我们不需要关心PCM最终编码采用的是什么计算方式，我们只需要知道PCM编码的音频流的优点和缺点就可以了。PCM编码的最大的优点就是音质好，最大的缺点就是体积大。我们常见的Audio CD就采用了PCM编码，一张光盘的容量只能容纳72分钟的音乐信息。
2.2.2 WAV
这是一种古老的音频文件格式，由微软开发。WAV是一种文件格式，符合RIFF (Resource Interchange File Format) 规范。所有的WAV都有一个文件头，这个文件头包含了音频流的编码参数。WAV对音频流的编码没有硬性规定，除了PCM之外，还有几乎所有支持ACM规范的编码都可以为WAV的音频流进行编码。WAV可以使用多种音频编码来压缩其音频流，不过我们常见的都是音频流被PCM编码处理的WAV，但这不表示WAV只能使用PCM编码，MP3编码同样也可以运用在WAV中，只要安装好了相应的Decode，就可以欣赏这些WAV了。在Windows平台下，基于PCM编码的WAV是被支持得最好的音频格式，所有音频软件都能完美支持，由于本身可以达到较高的音质的要求，因此，WAV也是音乐编辑创作的首选格式，适合保存音乐素材。因此，基于PCM编码的WAV被作为了一种中介的格式，常常使用在其他编码的相互转换之中，例如MP3转换成WMA。
2.2.3 MP3
MP3作为目前最为普及的音频压缩格式，为大家所大量接受，各种与MP3相关的软件产品层出不穷，而且更多的硬件产品也开始支持MP3，我们能够买到的VCD/DVD播放机都很多都能够支持MP3，还有更多的便携的MP3播放器等等，虽然几大音乐商极其反感这种开放的格式，但也无法阻止这种音频压缩的格式的生存与流传。MP3发展已经有10个年头了，他是MPEG(MPEG：Moving Picture Experts Group) Audio Layer-3的简称，是MPEG1的衍生编码方案，1993年由德国Fraunhofer IIS研究院和汤姆生公司合作发展成功。MP3可以做到12:1的惊人压缩比并保持基本可听的音质，在当年硬盘天价的日子里，MP3迅速被用户接受，随着网络的普及，MP3被数以亿计的用户接受。MP3编码技术的发布之初其实是非常不完善的，由于缺乏对声音和人耳听觉的研究，早期的mp3编码器几乎全是以粗暴方式来编码，音质破坏严重。随着新技术的不断导入，mp3编码技术一次一次的被改良，其中有2次重大技术上的改进。
2.2.4 OGG编码
Ogg Vorbis的音频编码，OGG是一个庞大的多媒体开发
计划
项目进度计划表范例计划下载计划下载计划下载课程教学计划下载
的项目名称，将涉及视频音频等方面的编码开发。整个OGG项目计划的目的就是向任何人提供完全免费多媒体编码方案。OGG的信念就是：OPEN，FREE，Vorbis。这几个个
词汇
英语3500词汇语境记忆pets3考试词汇二年级反义词和近义词初中词汇词汇大全考研英语二高频词汇表
成为了OGG项目中音频编码的正式命名。目前Vorbis已经开发成功，并且开发出了编码器。Ogg Vorbis是高质量的音频编码方案，官方数据显示：Ogg Vorbis可以在相对较低的数据速率下实现比MP3更好的音质。Ogg Vorbis这种编码也远比90年代开发成功的MP3先进，她可以支持多个声道，这意味着Ogg Vorbis在SACD、DTSCD、DVD AUDIO抓轨软件的支持下，可以对所有的声道进行编码，而不是MP3只能编码2个声道。多声道音乐的兴起，给音乐欣赏带来了革命性的变化，尤其在欣赏交响时，会带来更多临场感。这场革命性的变化是MP3无法适应的。和MP3一样，Ogg Vorbis是一种灵活开放的音频编码，能够在编码方案已经固定下来后还能对音质进行明显的调节和新算法的改良。因此，它的声音质量将会越来越好，和MP3相似，Ogg Vorbis更像一个音频编码框架，可以不断导入新技术逐步完善。和MP3一样，OGG也支持VBR。
2.2.5 MP3PRO编码
MP3PRO并不是一种全新的格式，完全是基于传统MP3编码技术的一种改良，本身最大的技术亮点就在于SBR（Spectral Band Replication 频段复制），这是一种新的音频编码增强算法。它提供了改善低位率情况下音频和语音编码的性能的可能。这种方法可在指定的位率下增加音频的带宽或改善编码效率。SBR最大的优势就是在低数据速率下实现非常高效的编码，与传统的编码技术不同的是，SBR更像是一种后处理技术，因此解码器的算法的优劣直接影响到音质的好坏。高频实际上是由解码器（播放器）产生的，SBR编码的数据更像是一种产生高频的命令集，或者称为指导性的信号源。MP3PRO其实是一种MP3信号流和SBR信号流的混合数据流编码。SBR技术可以改善低数据流量下的高频音质，改善程度约为30%，这种改善可以让64kbps的MP3达到128kbps的MP3的音质水平。
2.2.6 ACC格式
AAC（高级音频编码技术，Adavanced Audio Coding）是杜比实验室为音乐社区提供的技术。AAC号称最大能容纳48通道的音轨，采样率达96KHZ，并且在320Kbps的数据速率下能为5.1声道音乐提供相当于ITU-R广播的品质。和MP3比起来，它的音质比较好，它能够节省大余额30%的存储空间与带宽。它是遵循MPEG-2的规格所开发的技术。
2.3 音频解析
2.3.1 MP3文件解析
MP3的文件格式称为ID3，一般是位于一个MP3文件的开头或末尾的若干字节内，附加了关于该MP3的歌手，标题，专辑名称，年代，风格等信息，该信息就被称为ID3信息，ID3信息分为两个版本，v1和v2版。其中：v1版的ID3在MP3文件的末尾128字节，以TAG三个字符开头，后面跟上歌曲信息。其中流派一共定义了79种。v2版一般位于mp3的开头，可以存储歌词，该专辑的图片等大容量的信息。ID3V2一共有4个版本，但流行的播放软件一般只支持第3版，即ID3v2.3。由于ID3V1记录在MP3文件的末尾，ID3V2就只好记录在MP3文件的首部了。也正是由于这个原因，对ID3V2的操作比ID3V1要慢。而且ID3V2结构比ID3V1的结构要复杂得多，但比前者全面且可以伸缩和扩展。
ID3V1比较简单，它是存放在MP3文件的末尾，用16进制的编辑器打开一个MP3文件，查看其末尾的128个顺序存放字节，数据结构定义如下：
char Header[3]; /*标签头必须是"TAG"否则认为没有标签*/
char Title[30]; /*标题*/
char Artist[30]; /*作者*/
char Album[30]; /*专集*/
char Year[4]; /*出品年代*/
char Comment[30]; /*备注*/
char Genre; /*类型*/
ID3V1的各项信息都是顺序存放，没有任何标识将其分开，比如标题信息不足30个字节，则使用'\0'补足，否则将造成信息错误。Genre使用原码表示，对照表如下：
/* Standard genres */
0="Blues";1="ClassicRock";2="Country";3="Dance";4="Disco";5="Funk";6="Grunge";7="Hip-Hop";8="Jazz";9="Metal";10="NewAge";11="Oldies";12="Other";13="Pop";14="R&B";15="Rap";16="Reggae";17="Rock";18="Techno";19="Industrial";
20="Alternative";21="Ska";22="DeathMetal";23="Pranks";24="Soundtrack";25="Euro-Techno";26="Ambient";27="Trip-Hop";28="Vocal";29="Jazz+Funk";30="Fusion";31="Trance";32="Classical";33="Instrumental";34="Acid";35="House";36="Game";37="SoundClip";38="Gospel";39="Noise";40="AlternRock";41="Bass";42="Soul";43="Punk";44="Space";45="Meditative";46="InstrumentalPop";47="InstrumentalRock";48="Ethnic";49="Gothic";50="Darkwave";51="Techno-Industrial";52="Electronic";53="Pop-Folk";54="Eurodance";55="Dream";56="SouthernRock";57="Comedy";58="Cult";59="Gangsta";60="Top40";61="ChristianRap";62="Pop/Funk";63="Jungle";64="NativeAmerican";65="Cabaret";66="NewWave";67="Psychadelic";68="Rave";69="Showtunes";70="Trailer";71="Lo-Fi";72="Tribal";73="AcidPunk";74="AcidJazz";75="Polka";76="Retro";77="Musical";78="Rock&Roll";79="HardRock";
/* Extended genres */
80="Folk";81="Folk-Rock";82="NationalFolk";83="Swing";84="FastFusion";85="Bebob";86="Latin";87="Revival";88="Celtic";89="Bluegrass";90="Avantgarde";91="GothicRock";92="ProgessiveRock";93="PsychedelicRock";94="SymphonicRock";95="SlowRock";96="BigBand";97="Chorus";98="EasyListening";99="Acoustic";100="Humour";101="Speech";102="Chanson";103="Opera";104="ChamberMusic";105="Sonata";106="Symphony";107="BootyBass";108="Primus";109="PornGroove";110="Satire";111="SlowJam";112="Club";113="Tango";114="Samba";115="Folklore";116="Ballad";117="PowerBallad";118="RhythmicSoul";119="Freestyle";120="Duet";121="PunkRock";122="DrumSolo";123="Acapella";124="Euro-House";125="DanceHall";126="Goa";127="Drum&Bass";128="Club-House";129="Hardcore";130="Terror";131="Indie";132="BritPop";133="Negerpunk";134="PolskPunk";135="Beat";136="ChristianGangstaRap";137="HeavyMetal";138="BlackMetal";139="Crossover";140="ContemporaryChristian";141="ChristianRock";142="Merengue";143="Salsa";144="TrashMetal";145="Anime";146="JPop";147="Synthpop";
每个ID3V2.3的标签都由一个标签头和若干个标签帧或一个扩展标签头组成。关于曲目的信息如标题、作者等都存放在不同的标签帧中，扩展标签头和标签帧并不是必要的，但每个标签至少要有一个标签帧。标签头和标签帧一起顺序存放在MP3文件的首部。标签头在文件的首部顺序记录10个字节的ID3V2.3的头部。在文件的首部顺序记录10个字节的ID3V2.3的头部。数据结构如下：
char Header[3]; /*必须为"ID3"否则认为标签不存在*/
char Ver; /*版本号;ID3V2.3就记录03,ID3V2.4就记录04*/
char Revision; /*副版本号;此版本记录为00*/
char Flag; /*存放标志的字节，这个版本只定义了三位，稍后详细解说*/
char Size[4]; /*标签大小，包括标签帧和扩展标签头。（不包括标签头的10个字节）*/
2.3.2 WMA文件解析
每一个WMA文件，它的头16个字节是固定的，为十六进制的“30 26 B2 75 8E 66 CF 11 A6 D9 00 AA 00 62 CE 6C”，用来标识这个是否为WMA文件。接下来的8个字节为一个整数，表示整个WMA文件头部的大小，这个头部里面包含了Tag信息等所有非音频信息，头部后面的是音频信息。也就是说从文件开始偏移量为31开始，里面存放了很多帧，有我们需要的标准Tag信息，扩展Tag信息，WMA文件控制信息等等。每个帧不是等长的，但是帧头是固定的24个字节，其中前16字节是用来标识这个帧的名字，后8个字节是用来表示这个帧（包括帧头）的大小。这一点和MP3文件的ID3V2信息比 较像。Tag信息分别保存在两个帧里，分别为标准Tag帧和扩展Tag帧。
标准Tag帧只包含歌曲标题，艺术家，版权，备注四个内容。它的帧名是十六进制的“3326 B2 75 8E 66 CF 11 A6 D9 00 AA 00 62 CE 6C”，在24个字节的帧头后紧跟着5个分别为2个字节的整数，分别表示歌曲标题，艺术家，版权，备注，未知信息的大小，未知信息大部分情况下是不使用的，即它的大小为0的。在这10个字节后，这五个信息的内容就按顺序存放了。记住，在WMA文件里，所有的文字都是按Unicode宽字符的编码方式储存的，而且每个字符串后面都有一个0x00 0x00结束字符的。
扩展Tag帧里面包含的信息的个数是不确定的，每个信息也是按照像帧一样的方式组织起来的。扩展Tag帧的帧名是十六进制的“40 A4 D0 D2 07 E3 D2 11 97 F000 A0 C9 5E A8 50”，在24字节的帧头(HeadFlag:16，HeadSize:8)后先有一个两个字节的整数表示这个帧里一共有的扩展信息个数（ExNo）。紧接着是扩展信息。每一个扩展信息包含扩展信息名字大小（2字节）和对应的内容。先有一个两个字节的整数来表示扩展名字信息的大小，接着是扩展信息名称，然后有一个两个字节的整数标志（Flag）。然后又是一个两个字节的整数，表示值的大小。接着就是这个值。当扩展信息名字为WMFSDKVersion时，这个值表示的是这个WMA文件的版本；当扩展信息名字为WM/AlbumTitle时，这个值代表的就是专辑名；当扩展信息名字为WM/Genre时，这个值代表的就是流派。很容易从扩展信息的名字看出这个值的用途。这些扩展信息的名字和值几乎都是用Unicode的字符串来存储的，到现在为止只发现对下面两个情况例外。标志Flag，只对WM/TrackNumber和WM/Track这两个扩展信息名字有用，当Flag为3的时候后面的值是以4个字节的整数的形式表示，当Flag为0的时候，曲目信息是以普通的字符串形式表示的。
WMA格式有一个帧全部都是0，相当于缓冲区。如果写入的歌名比原来长的话，就减少缓冲区大小，歌名短就增加缓冲区。这样就可以保持文件头的大小不变，每次更新的话只需要重写文件头，不需要重写音频数据。这6个 字节其中前面4个字节为总标签帧数。
2.3.3 OGG文件的解析
“Ogg”意指一种文件格式，可以纳入各式各样自由和开放源代码的编解码器，包含音效、视频、文字（像字幕）与元数据的处理。在Ogg的多媒体框架下，Theora提供有损的图像层面，而通常用音乐导向的Vorbis编解码器作为音效层面。针对语音设计的压缩编解码器Speex和无损的音效压缩编解码器FLAC与OggPCM也可能作为音效层面使用。OGG文件的组织形式，OGG是以页（page）为单位将逻辑流组织链接起来，每个页都有pageheader和pagedata。OGG page页结构，每个页之间相互独立，都包含了各自应有的信息，页的大小是可变的，通常为4K－8KB，最大值不能超过65307bytes（27＋255＋255*255=65307）。OGG页头部结构，页标识：ASCII字符，0x4f 'O' 0x67 'g' 0x67 'g' 0x53 'S'，4个字节大小，它标识着一个页的开始。其作用是分离Ogg封装格式还原媒体编码时识别新页的作用； 版本id：一般当前版本默认为0，1个字节；Header_type：标识当前的页的类型，1个字节；Granule_position：媒体编码相关的参数信息，8个字节，对于音频流来说，它存储着到本页为止逻辑流在PCM输出中采样码的数目，可以由它来算得时间戳。对于视频流来说，它存储着到本页为止视频帧编码的数目。若此值为-1，那表示截止到本页，逻辑流的packet未结束；Serial_number：当前页中的流的id，4个字节，它是区分本页所属逻辑流与其他逻辑流的序号，我们可以通过这个值来划分流。(小端)。Page_seguence：本页在逻辑流的序号，4个字节。OGG解码器能据此识别有无页丢失；CRC_cbecksum：循环冗余校验码校验和，4个字节，包含页的32bit CRC校验和（包括头部零CRC校验和页数据校验），它的产生多项式为：0x04c11db7；Num _segments：给定本页在segment_table域中出现的segement个数，1个字节。其最大值为255.页最大物理尺寸为65307bytes,小于64KB；Segment_table：从字面看它就是一个表，表示着每个segment的长度，取值范围是0~255。由segment可以得到packet的值，每个packet的大小是以最后一个不等于255的segment结束的，从页头中的segment_table可以得到每个packet长度。
2.4 Qt的事件模型
Qt中的事件模型十分重要。
2.4.1 事件的概念
应用程序对象将系统消息接收为Qt事件。应用程序可以按照不同的粒度对事件加以监控、过滤并做出响应。在Qt中，事件是指从QEvent继承的对象。Qt将事件发送给每个QObject对象，这样对象便可对事件做出响应。也就是说，Qt的事件处理机制主要是基于QEvent类来实现的，QEvent类是其他事件类的基类。当一个事件产生时，Qt 就会构造一个QEvent子类的实例来表述该事件，然后将该事件发送到相应的对象上进行处理。
编程人员可以对应用程序级别和对象级别中的事件进行监控和过滤。
2.4.2 事件的创建
大多数事件是由窗口系统生成的，它们负责向应用程序通知相关的用户操作，例如：按键、鼠标单击或者重新调整窗口大小。也可以从编程角度来模拟这类事件。在Qt中大约有50多种事件类型，最常见的事件类型是报告鼠标活动、按键、重绘请求以及窗口处理操作。编程人员也可以添加自己的活动行为，类似于内建事件的事件类型。
通常，接收方如果只知道按键了或者松开鼠标按钮了，这是不够的。例如，它还必须知道按的是哪个键，松开的是哪个鼠标按钮以及鼠标所在位置。每一 QEvent 子类均提供事件类型的相关附加信息，因此每个事件处理器均可利用此信息采取相应处理。
2.4.3 事件的交付
Qt通过调用虚函数 QObject::event()来交付事件。
出于方便起见，QObject::event()会将大多数常见的事件类型转发给专门的处理函数，例如：QWidget::mouseReleaseEvent()和QWidget::keyPressEvent()。开发人员在编写自己的控件时，或者对现有控件进行定制时，可以轻松地重新实现这些处理函数。
有些事件会立即发送，而另一些事件则需要排队等候，当控制权返回至Qt事件循环时才会开始分发。Qt使用排队来优化特定类型的事件。例如，Qt会将多个paint事件压缩成一个事件，以便达到最大速度。
通常，一个对象需要查看另一对象的事件，以便可以对事件做出响应或阻塞事件。这可以通过调用被监控对象的 QObject::installEventFilter() 函数来实现。实施监控对象的QObject::eventFilter() 虚函数会在受监控的对象在接收事件之前被调用。
另外，如果在应用程序的 QApplication 唯一实例中安装一个过滤器，则也可以过滤应用程序的全部事件。系统先调用这类过滤器，然后再调用任何窗体特定的过滤器。开发人员甚至还可以重新实现事件调度程序 QApplication::notify()，对整个事件交付过程进行全面控制。
2.4.4 事件循环模型
Qt通过调用虚函数QObject：：event()来交付事件。处于方便起见，Qobject：：event()会将大多数的事件类型转发给专门的处理函数：
例如：QWidget::mouseReleaseEvent()和 QWidget::keyPressEvent()。开发人员在编写自己的控件时，或者对现有控件进行定制时，可以轻松地重新实现这些处理函数。
有些事件会立即发送，而另一些事件则需要排队等候，当控制权返回至Qt事件循环时才会开始分发。Qt使用排队来优化特定类型的事件。例如，Qt会将多个paint事件压缩成一个事件，以便达到最大速度。
通常，一个对象需要查看另一对象的事件，以便可以对事件做出响应或阻塞事件。这可以通过调用被监控对象的 QObject::installEventFilter() 函数来实现。实施监控对象的QObject::eventFilter() 虚函数会在受监控的对象在接收事件之前被调用。
另外，如果在应用程序的QApplication 唯一实例中安装一个过滤器，则也可以过滤应用程序的全部事件。系统先调用这类过滤器，然后再调用任何窗体特定的过滤器。开发人员甚至还可以重新实现事件调度程序 QApplication::notify()，对整个事件交付过程进行全面控制。
2.4.5 自定义事件
一般有下列5种方式可以用来处理和过滤事件，每种方式都有其使用条件和使用范围。
重载paintEvent()、mousePressEvent()等时间处理器(event handler)重新实现像mousePressEvent(),keyPressEvent()和paintEvent()这样的event hangder是目前处理event所采用的最常见的方法。
重载QcoreApplication::notify()函数
这种方式能够对事件处理进行完全控制。也就是说，当你需要在事件处理器(event handler)之前得到所有事件的话，就可以采用这个方法，但是这样一来，因为只有一个notify()函数，所以每次只能有一个子类被激活。这与事件过滤器不同，因为后者可以有任意数目并且同时存在。
在QCoreApplication：：instance（）上安装时间过滤器
这样就可以处理所有部件上的所有事件，这和重载QcoreApplication::notify()函数的效果是类似的。一旦一个eventfilter被注册到qApp，程序里发到其它对象的事件发到其它的eventfilter之前，都要首先发到这个eventfileter上。
重载QObject::event()函数
通过重新实现的event()函数，在事件到达特定部件的事件过滤器前处理Tab事件。需要注意的是，当重新实现某个子类的event()，需要调用基类的event()来处理不准备显示处理的情况。
在选定对象上安装事件过滤器
该对象继承自QObject，这样就可以处理处理Tab和Shift-Tab以外的所有事件。当对象用installEventFilter()注册之后，所有发送到该对象的事件都会经过监测它的eventfilter（）注册之后，所有发到该对象的事件都会先经过监测它的eventfilter。如果该object同时安装了多个eventfilter，那么这些filter会按照“后进先出”的规则依次被激活，及顺序是从最后安装的开始，到第一个被安装的为止。
2.5 Qt核心机制信号与槽
信号和槽机制是Qt的核心机制之一，要掌握Qt编程就需要对信号和槽有所了解。信号和槽是一种高级接口，它们被应用于对象之间的通信，它们是Qt的核心特性，也是Qt不同于其它同类工具包的重要地方之一。在我们所了解的其它GUI工具包中，窗口小部件(widget)都有一个回调函数用于响应它们触发的动作，这个回调函数通常是一个指向某个函数的指针。在Qt中用信号和槽取代了上述机制。
2.5.1 信号
当对象的状态发生改变时，信号被某一个对象发射。只有定义过这个信号的类或者其派生类能够发射这个信号。当一个信号被发射时，与其相关联的槽将被执行，就像一个普通的函数调用一样。信号-槽机制独立于任何GUI事件循环。只有当所有的槽正确返回以后，发射函数才返回。如果存在多个槽与某个信号相关联，那么，当这个信号被发射时，这些槽将会一个接一个地被执行，但是它们执行的顺序将会是不确定的，并且不能指定它们执行的顺序。信号的声明是在头文件中进行的，并且moc工具会注意不要将信号定义在实现文件中。Qt用signals关键字标识信号声明区，随后可声明自己的信号。
2.5.2 槽
槽是普通的C++成员函数，可以被正常调用，不同之处是它们可以与信号（signal）相关联。当与其关联的信号被发射时，这个槽就会被调用。槽可以有参数，但槽的参数不能有缺省值。
槽也和普通成员函数一样有访问权限。槽的访问权限决定了谁可以和它相连。通常，槽也分为三种类型，即public slots、private slots和protected slots。public slots：在这个代码区段内声明的槽意味着任何对象都可将信号与之相连接。这对于组件编程来说非常有用：你生成了许多对象，它们互相并不知道，把它们的信号和槽连接起来，这样信息就可以正确地传递，并且就像一个小孩子喜欢玩耍的铁路轨道上的火车模型，把它打开然后让它跑起来。protected slots：在这个代码区段内声明的槽意味着当前类及其子类可以将信号与之相关联。这些槽只是类的实现的一部分，而不是它和外界的接口。private slots：在这个代码区段内声明的槽意味着只有类自己可以将信号与之相关联。这就是说这些槽和这个类是非常紧密的，甚至它的子类都没有获得连接权利这样的信任。通常，我们使用public和private声明槽是比较常见的，建议尽量不要使用protected关键字来修饰槽的属性。此外，槽也能够声明为虚函数。槽的声明也是在头文件中进行的。
2.5.3 信号与槽的关联
槽和普通的C++成员函数几乎是一样的，可以是虚函数；可以被重载；可以是公有的、保护的或是私有的，并且也可以被其它C++成员函数直接调用；还有，它们的参数可以是任意类型。唯一不同的是：槽还可以和信号连接在一起，在这种情况下，每当发射这个信号的时候，就会自动调用这个槽。一个信号可以连接多个槽；多个信号可以连接同一个槽；一个信号可以与另外一个信号相连接； 连接可以被移除；信号成功连接到槽（或者连接到另外一个信号），它们的参数必须具有相同的顺序和相同的类型，如果信号的参数比它所连接的槽的参数多，那么多余的参数将会被简单的忽略掉。
3 需求分析
3.1 需求概述
在需求分析阶段，我们采用UML建模，目的是捕捉系统的所有功能需求加以描述，同时建立模型，分析并提取所开发系统的各种可以模块化的功能以及描述它们的联系。
音频管理系统的基本需求如下：
它是一个音频管理单机系统，打开一个文件加入到播放列表的同时将这些音乐文件分类。
以演唱者分类，并且以演唱者作为树根节点，分列加入这个演唱者的歌曲。
以专辑名称分类，以专辑名称作为树根节点，分列加入这个专辑的歌曲。
加入到播放列表的歌曲可以实现基本的播放功能。
播放/暂停功能。双击歌曲，可以播放歌曲。
上一首/下一首。按播放列表歌曲的加入顺序，播放当前歌曲的上一曲和下一曲。
停止。当前歌曲可以停止。
播放进度条。播放进度条可以显示当前歌曲总的播放时间以及当前已播放的时间。拉动进度条可以实现快进功能。
静音。点击声音的图标，点击按钮，实现静音。拉动音量滚动条，可以实现音量的控制。
3.2 系统用例图
在本系统中，通过分析，可以确定只有一种角色，就是用户。这个角色执行的功能，也就是系统做需求分析时所定义的功能。系统用例图如图3.1所示。
3.3 系统关键领域类
本系统是按照功能划分实现的。根据系统的功能，列出系统中特定领域类。本系统中，通过系统用例分析可以发现，本系统主要有以下关键领域类，树形显示（歌手，专辑名称）类，播放列表类，播放控制类。
系统中的一个功能亮点是管理。打开一个本地文件，加入到播放列表的同时对当前歌曲文件进行解析，以演唱者作为分类显示歌曲名，以树型显示比较清晰，可以达到管理的功能。同理，以专辑名称作为分类显示歌曲名也需要同样的方法。树形显示类抽象出来，可以节省代码，有利于功能的扩展。
系统中的另外一个功能就是播放。播放控制，播放列表都用类抽象出来，把这些功能组合在一起，代码看起来更加的整齐，按照低耦合的标准，方便扩展。
4 系统设计
4.1 系统介绍
用Qt设计实现音频管理系统在我所接触到的资料中并不多见。本系统中实现了以演唱者分类管理歌曲名，以专辑名称分类管理歌曲名，音乐文件的播放，暂停，停止，上一首，下一首，静音，音量控制，播放进度。本系统是运用可视化编程工具Qt开发的，界面美观大方，系统运行稳定。本系统可以运行于各种装有Qt5.2版本的系统中。
4.2 主要功能
本系统的功能划分如下：
以演唱者分类管理音乐文件：系统可以根据打开的文件自动按照演唱者分类加入该演唱者对应的歌曲名。
以专辑名称分类管理音乐文件：系统可以根据打开的文件自动按照专辑名称分类加入该专辑对应的歌曲名。
播放/暂停功能。双击播放列表，可以播放文件。选中播放列表中显示的歌曲名，单机播放按钮，也可以播放音频文件。
停止功能。点击停止播放按钮，可以停止播放。
上一首。点击上一首按钮，可以播放上一首歌曲。
下一首。点击下一首按钮，可以播放下一首歌曲。
静音。点击音量图标，实现静音功能。
音量控制。拖动音量滑动条，实现音量控制。
播放进度条功能。拖动播放进度条，实现快进。
4.3 系统总体模块
4.3.1 系统总体模块介绍
系统按照两个模块来划分。系统界面模块和系统功能模块。
系统界面模块就按照界面布局来介绍，艺术家以及其对应的音频文件显示，专辑名以及对应的音频文件显示，播放列表。每个艺术家都作为一个节点，艺术家的歌曲作为其子节点。每张专辑也可以作为一个节点，专辑的歌曲作为其子节点。这样用户可以清晰的看出本地系统中的音频文件。从系统中查找到的音频文件加入到播放列表中，双击播放列表中的歌曲名称可以播放音频文件。这三个小的模块都用于显示读取到的音频文件名称。尤其是系统的管理功能可以得到体现。此外还有打开按钮，播放控制以及播放进度条。
系统功能模块按照功能划分：音频文件管理功能，音频播放控制，播放列表，播放进度。
4.3.2 系统层次图
4.4 系统界面模块介绍
4.4.1 主页面
系统只有一个页面。主页面要显示本地系统的相应信息。主页面中对各类信息按类型显示。主页面显示播放控制条，播放进度条，还有播放列表，分类显示框。
最上面是播放进度条。播放进度条的右侧是播放的总时间和当前播放时间。
中间这一层放置的是打开文件的按钮。打开文件按钮的右侧是播放进度条。播放进度条上面有各种和播放相关的按钮。播放进度条的右侧是全屏按钮。
下面这一层放置的是当前系统中的音频文件。这一层有三个框。左边放置的是以艺术家分类管理的音频文件。中间这一栏放置的是以专辑名称分类管理的音频文件。最右边放置的是播放列表。
主页面的运行结果如图4.2所示。
4.4.2 以演唱者分类，显示演唱者所对应的歌曲名
系统管理音频文件，可以根据打开的文件自动按照演唱者分类加入该演唱者对应的歌曲名。以树形显示歌手和相应的歌曲。歌手为根节点，歌曲为叶节点。
运行结果如图4.3所示。
INCLUDEPICTURE "../AppData/Local/Temp/ksohtml/wps_clip_image-1487.png" \* MERGEFORMAT
4.4.3 以专辑名称分类，显示该专辑所对应的歌曲名
系统管理音频文件，可以根据打开的文件自动按照专辑分类加入该演唱者对应的歌曲名。以树形显示专辑和相应的歌曲。专辑为根节点，歌曲为叶节点。
运行结果如图4.4所示。
INCLUDEPICTURE "../AppData/Local/Temp/ksohtml/wps_clip_image-23449.png" \* MERGEFORMAT
4.4.4 播放列表
实现播放功能，需要一个播放列表。双击选中歌曲，可以播放音乐。播放列表中的歌曲按照添加进系统的先后顺序顺序播放。要实现这些功能需要重写QAbstractItemModel，添加一些槽函数。
运行结果如4.5所示。
4.4.5 播放控制相关按钮
实现播放控制。开始，停止，上一首，下一首，音量控制，静音功能，播放速度。这几个都是与音乐播放有关的功能。
运行结果如4.6所示。
INCLUDEPICTURE "../AppData/Local/Temp/ksohtml/wps_clip_image-466.png" \* MERGEFORMAT
4.4.6 播放进度条
播放进度条是一条可移动的滑条，右侧显示当前已播放时间和当前播放文件的总时间。
运行结果如图4.7所示。
4.4.7 打开按钮
open按钮，这个按钮触发打开文件对话框操作。打开文件对话框，可取的音频文件名，系统的所有操作都是基于这个结果之上。
运行结果如图4.8所示。
4.5 系统功能模块划分
根据系统的功能，列出系统中的几个模块。本系统中，通过分析可以发现，本系统主要有以下模块，音频文件管理模块，音频文件播放模块，播放列表模块，播放进度模块。
系统的一个功能亮点是管理。打开一个本地文件，加入到播放列表的同时对当前歌曲文件进行解析，以演唱者作为分类显示歌曲名，以树型显示比较清晰，可以达到管理的功能。同理，以专辑名称作为分类显示歌曲名也需要同样的方法。管理功能单独抽象成一个模块，适合扩展。
系统中的另外一个功能就是播放。与播放有关的两个功能：播放控制，播放列表。播放控制，播放列表都写成独立的模块。主程序看起来简单。易懂。同样也适合扩展。
功能模块层次图4.9所示。
4.5.1 音频文件管理
以演唱者分类，管理演唱者所对应的歌曲名
系统管理音频文件，可以根据打开的文件自动按照演唱者分类加入该演唱者对应的歌曲名。一个演唱者有多首歌曲，也就是说建立演唱者的时候，把它的相应的歌曲添加在该节点之下。要实现这个功能需要使用QTreeview，以树形显示歌手和相应的歌曲。歌手为根节点，歌曲为叶节点。
以专辑名称分类，显示该专辑所对应的歌曲名。
系统管理音频文件，可以根据打开的文件自动按照专辑分类加入该演唱者对应的歌曲名。一张专辑有多首歌曲，也就是说建立专辑的时候，把它相应的歌曲添加到该节点之下。要实现这个功能需要使用QTreeview，以树形显示专辑和相应的歌曲。专辑为根节点，歌曲为叶节点。
4.5.2 播放控制
播放控制。播放控制的基本功能：
播放/暂停功能。双击播放列表，可以播放音频文件。选中播放列表中显示的歌曲名，单击播放按钮，可以播放音频文件。
停止功能。点击停止播放按钮，可以停止播放音频文件。
上一首。点击上一首按钮，可以播放当前播放列表的播放歌曲的上一首歌曲。
下一首。点击下一首按钮，可以播放当前播放列表的播放歌曲的下一首歌曲。
静音。点击音量图标，实现静音功能。点击静音图标，声音可以播放。
音量控制。拖动音量滑动条，滑动条越高，音量越大。
播放速度控制。选择那三个速度选项，可以改变播放速度。
4.5.3 播放列表
实现播放功能，需要一个播放列表。双击选中歌曲，可以播放音乐。播放列表中的歌曲按照添加进系统的先后顺序顺序播放。要实现这些功能需要重写QAbstractItemModel，添加一些槽函数。
4.6 系统开发环境
硬件条件：HP ProBook 6450b
系统开发平台：Qt Creator5.2
系统运行平台：win7，Ubuntu
5 系统实现
5.1 树形结构显示
应用程序中往往要存储大量的数据，并对它们进行处理，然后可以通过各种形式显示给用户，用户需要时还可以对数据进行编辑。Qt中的模型/视图就是用来实现大量数据的存储、处理及显示的。数据和界面的进行分离，使得相同的数据在多个不同的视图中显示成为可能，而且还可以创建新的视图，而不需要改变底层的数据框架。所有的模型都基于QAbstractItemModel类，这个类定义了一个接口来处理各种视图。这些数据表现为表格，列表和树。
在模型/视图架构中，模型提供了一个标准的接口供视图和委托来访问数据，在Qt中这个标准的接口使用QAbstractItemModel类来定义。
Qt提供了几种不同类型的视图，它们都完全实现了各自的功能。QTreeView将模型的数据显示在具有层次结构的表中。这个类中提供一些方法，可以建立根节点，添加元素到根节点。在主文件的构造函数中实例化该类的对象，便可将它以树形结构显示出来。
5.1.1 主要相关代码及说明
以树形结构添加演唱者及它的歌曲，以树形结构显示专辑名称及它的歌曲。QTreeView是QtGui里面提供的一种树形结构。这种结构可以添加节点，并在节点下面继续添加节点，最末的一层作为叶子。系统中重写QTreeView，添加成员变量i，设置添加树形结构中的行位置，添加两个成员函数addArtistMember(char *artist,char *fileName),addAlbumMember(char *album, char *fileName)两个函数实现为艺术家树结构添加音频节点功能和为专辑名称添加音频节点功能，从而实现以艺术家和专辑名称管理音频文件。以艺术家分类管理音频文件的设计思想是，本系统读取的每个音频文件，读取其中的艺术家，若该艺术家第一次出现在系统中，为其新建一个节点，并将歌曲名称添加到该节点，并且显示出来；若所读取到的艺术家的歌曲已经添加到系统中，则直接将歌曲名称添加到该节点。以专辑名称分类的思想类似，不做具体描述。
实现艺术家如图5.1所示。
具体实现的关键技术代码如下：
Mytreeview.cpp
//构造函数
MyTreeView::MyTreeView(QWidget *parent):QTreeView(parent)
{
i=0;//记录行数
model=new QStandardItemModel(4,1);
}
//将歌曲添加到歌手对应的演唱者节点中
void MyTreeView::addArtistMember(char *artist,char *fileName)
{
//添加演唱者
model->setHeaderData(0,Qt::Horizontal,"artist");
QList
list=this->returnTheItems();
//遍历表，如果歌手已经添加，不需要创建新节点直接添加歌曲
foreach (QStandardItem *item, list) {
if(item->text()==artist){
QStandardItem *item1=new QStandardItem(fileName);
//item1->setData(fileName);
item->appendRow(item1);
this->setModel(model);
return;
}
}
//创建新歌手节点
item_artist=new QStandardItem(artist);
model->setItem(i++,0,item_artist);
//添加歌曲到歌手
QStandardItem *item1=new QStandardItem(fileName);
item_artist->appendRow(item1);
//为视图指定模型
this->setModel(model);
}
//将歌曲添加到对应的专辑名称节点中
void MyTreeView::addAlbumMember(char *album, char *fileName)
{
//遍历表，如果专辑名称已经被添加，不创建新节点直接添加音频文件
model->setHeaderData(0,Qt::Horizontal,"album");
QListlist=this->returnTheItems();
foreach (QStandardItem *item, list){
if(item->text()==album){
QStandardItem *item1=new QStandardItem(fileName);
item->appendRow(item1);
this->setModel(model);
return;
}
}
//创建新歌手节点
item_album=new QStandardItem(album);
model->setItem(i++,0,item_album);
//添加歌曲到专辑
QStandardItem *item1=new QStandardItem(fileName);
item_album->appendRow(item1);
this->setModel(model);
}
5.1.2 关键技术应用中问题的解决
1.打开文件时，只能建立一个节点。
在自定义类MyTreeView的构造函数中，实例化model。设置行变量i，给树形视图添加条目，每添加一次，行变量自增一次。这样打开文件时，可以设置多个节点。
2.同一个演唱者的歌曲，如何加到那个演唱者目录下。
把当前结点的名称存放到list容器中，遍历list，如果List存在演唱者，跳过新建结点，直接添加条目。
5.2 播放列表
5.2.1 主要相关代码及说明
QAbstractItemModel是Qt提供的一个抽象接口项目模型类。该类定义了项目模型必须使用能够与互操作在模型/视图结构的其他组件的标准接口。不能直接实例化。可以作为项目视图类的底层数据模型。播放列表中需要导入播放列表的数据，实例化一个Playlist的类。音乐播放列表需要获取行数，获取列数，建立索引，添加数据，添加播放列表，添加数据。
头文件定义如下：
Playlistmodel.h
class PlaylistModel : public QAbstractItemModel
{
//使用信号和槽
Q_OBJECTpublic:
enum Column
{
Title = 0,
ColumnCount
};
PlaylistModel(QObject *parent = 0)
//获取行数
int rowCount(const QModelIndex &parent = QModelIndex()) const;
//获取列数
int columnCount(const QModelIndex &parent = QModelIndex()) const;
//建立索引
QModelIndex index(int row, int column, const QModelIndex &parent = QModelIndex()) const;
//添加数据
QModelIndex parent(const QModelIndex &child) const;
//播放列表
QVariant data(const QModelIndex &index, int role = Qt::DisplayRole) const;
//设置播放列表
QMediaPlaylist *playlist() const;
void setPlaylist(QMediaPlaylist *playlist);
//设置数据
bool setData(const QModelIndex &index, const QVariant &value, int role = Qt::DisplayRole);
private slots:
//插入
void beginInsertItems(int start, int end);
void endInsertItems();
//移除
void beginRemoveItems(int start, int end);
void endRemoveItems();
//改变
void changeItems(int start, int end);
private:
//播放列表
QMediaPlaylist *m_playlist;
//容器
QMap m_data;
};
设置播放列表的时候，要注意模型重置。模型时重置它意味着任何以前的数据报道从模型现在已经无效,必须再次查询。这也意味着当前项和任何选定的项目将成为无效。当一个模型从根本上改变其数据有时会容易只是调用这个函数,而不是dataChanged()来通知其他组件基础数据源时,或其结构,已经改变了。你必须在调用这个函数之前重置你的模型或代理模型的任何内部数据结构。代码如下所示：
playlistmodel.cpp
void PlaylistModel::setPlaylist(QMediaPlaylist *playlist)
{
if (m_playlist) {
disconnect(m_playlist,SIGNAL(mediaAboutToBeInserted(int,int)),this,SLOT(beginInsertItems(int,int)));
disconnect(m_playlist,SIGNAL(mediaInserted(int,int)),this,SLOT(endInsertItems()));
disconnect(m_playlist,SIGNAL(mediaAboutToBeRemoved(int,int)),this,SLOT(beginRemoveItems(int,int)));
disconnect(m_playlist,SIGNAL(mediaRemoved(int,int)),this,SLOT(endRemoveItems()));
disconnect(m_playlist,SIGNAL(mediaChanged(int,int)),this,SLOT(changeItems(int,int)));
}
//模型重置，调用此函数后重置任何内部数据结构在你的模型或代理模型
beginResetModel();
m_playlist = playlist;
if(m_playlist){
connect(m_playlist,SIGNAL(mediaAboutToBeInserted(int,int)),this,SLOT(beginInsertItems(int,int)));
connect(m_playlist,SIGNAL(mediaInserted(int,int)),this,SLOT(endInsertItems()));
connect(m_playlist,SIGNAL(mediaAboutToBeRemoved(int,int)),this,SLOT(beginRemoveItems(int,int)));
connect(m_playlist,SIGNAL(mediaRemoved(int,int)),this,SLOT(endRemoveItems()));
connect(m_playlist,SIGNAL(mediaChanged(int,int)),this,SLOT(changeItems(int,int)));
}
endResetModel();
}
//获取行数
int PlaylistModel::rowCount(const QModelIndex &parent) const
{
return m_playlist && !parent.isValid() ? m_playlist->mediaCount() : 0;
}
//获取列数
int PlaylistModel::columnCount(const QModelIndex &parent) const
{
return !parent.isValid() ? ColumnCount : 0;
}
//建立索引
QModelIndex PlaylistModel::index(int row, int column, const QModelIndex &parent) const
{
return m_playlist && !parent.isValid()
&& row >= 0 && row < m_playlist->mediaCount()
&& column >= 0 && column < ColumnCount? createIndex(row, column)
: QModelIndex();
}
QModelIndex PlaylistModel::parent(const QModelIndex &child) const
{
//用于抑制编译器警告
Q_UNUSED(child);
//创建一个新的空模型索引。这种类型的模型指数是用来表明,模型中的位置是无效的。
return QModelIndex();
}
//添加数据
QVariant PlaylistModel::data(const QModelIndex &index, int role) const
{
if (index.isValid() && role == Qt::DisplayRole) {
QVariant value = m_data[index];
if (!value.isValid() && index.column() == Title) {
QUrl location = m_playlist->media(index.row()).canonicalUrl();
return QFileInfo(location.path()).fileName();
}
return value;
}
return QVariant();
}
//播放列表
QMediaPlaylist *PlaylistModel::playlist() const
{
return m_playlist;
}
//设置数据
bool PlaylistModel::setData(const QModelIndex &index, const QVariant &value, int role)
{
//用于抑制编译器警告
Q_UNUSED(role);
m_data[index] = value;
emit dataChanged(index, index);
return true;
}
//槽函数,开始插入数据
void PlaylistModel::beginInsertItems(int start, int end)
{
m_data.clear();
beginInsertRows(QModelIndex(), start, end);
}
//槽函数,终止插入数据
void PlaylistModel::endInsertItems()
{
endInsertRows();
}
//槽函数,开始移除属性
void PlaylistModel::beginRemoveItems(int start, int end)
{
m_data.clear();
beginRemoveRows(QModelIndex(), start, end);
}
//槽函数
void PlaylistModel::endRemoveItems()
{
endInsertRows();
}
//槽函数,改变属性
void PlaylistModel::changeItems(int start, int end)
{
m_data.clear();
emit dataChanged(index(start,0), index(end,ColumnCount));
}
5.2.2 功能实现
媒体对象队列中的媒体源会一个接一个地自动播放，而且在两个媒体源切换时，不会改变媒体对象的状态，也就是说，在当前的媒体源播放时，媒体对象不会发生任何状态变化，依然处于PlayingState状态，那么当前媒体源播放结束后继续播放队列中的下一个媒体源时，媒体对象不会发生任何状态变化，依然处于PlayingState状态。当在播放列表中单击了一首歌曲时，要将其设置为当前的媒体元，并根据媒体对象的状态来判断是否进行播放。
5.3 读取MP3音频文件
点击open按钮，打开文件对话框，选中要播放的音频文件，解析该音频文件，将MP3中tag标签中有关歌曲的信息解析出来。
5.3.1 主要相关代码
open按钮，是QPushButton的对象，QPushButton有一个信号，clicked（），在该按钮被点击的时候发送的信号，信号的接收者是主窗体，主窗体自定义槽函数open（）处理信号。
Open按钮如图5.2所示。
实现代码如下：
openButton = new QPushButton("open", this);
connect(openButton, SIGNAL(clicked()), this, SLOT(open()));
open函数实现了保存文件名，将文件名添加到播放列表，打开该文件。保存文件名，QFileDialog的getOpenFileNames函数返回文件名。主窗体自定义函数addToPlaylist实现的功能是将文件名添加到播放列表。主窗体自定义函数openFile实现打开文件操作。
实现代码如下：
void Widget::open()
{
//这是有QFileDialog提供的一个函数,返回一个或多个文件供用户选用
QStringList fileNames = QFileDialog::getOpenFileNames(this,tr("Open Files"));
addToPlaylist(fileNames);
openFile(fileNames);
}
openFile函数实现打开文件操作，遍历open函数得到的文件名，如果文件可用，便将文件打开，读取文件信息。
openFile如图5.3所示。
实现代码如下：
//打开一个文件
void Widget::openFile(const QStringList &fileNames)
{
int i=0;
foreach (QString const &argument, fileNames){
QUrl url(argument);
if (url.isValid()){
QFile file(fileNames.at(i));
if(file.open(QFile::ReadOnly)){
QTextStream inStream(&file);
自定义函数ReadMp3Info，读取文件信息。
ReadMp3Info(fileNames.at(i++).toLocal8Bit().data());
file.flush();// //冲刷所有的缓冲数据到文件中
file.close();
}
}
}
}
Qt中提供了一些类提取歌曲名，演唱者，专辑。QMediaObect中的metadata函数,可以获取演唱者，专辑名称，标题，日期，风格，音轨编号，内容描述，光盘标识。在尝试使用的时候，始终没有找到这个函数的触发条件。基于Qt中支持C，我就利用C语言读取MP3音频文件的方法解析相对应的演唱者，专辑名称等。利用C语言读取音频文件中的演唱者，专辑名称需要定义一些全局变量，tag,用于验证该文件是否是ID3v1形式的标签，如果tag值不为“TAG”则表示不是一个标准可读信息的MP3文件，author存演唱者信息，title存歌曲名，disc_name存专辑名称。定义了函数ReadMp3Info(const char *fn)读取MP3信息。读取MP3信息的代码如下：
char tag1[3+1];
char author1[30+1];
char title1[30+1];
char year1[4+1];
char remark1[30+1];
char disc_name1[30+1];
//读取Mp3信息函数
bool ReadMp3Info(const char *fn)
{
FILE *fp;
fp = fopen( fn, "r" );
if( !fp )
return false;
//tag标签存放在文件最末的128个字节
fseek(fp, -128, SEEK_END );
fread(tag,1,3,fp);
tag[3]='\0';
//若tag是“TAG”，则是MP3文件
if(strcmp(tag, "TAG" ) != 0 )
return false;
Title，author，disc_name占30个字节
fread( title, 1, 30, fp );
fread( author, 1, 30, fp );
fread( disc_name, 1, 30, fp );
fread( year, 1, 4, fp );
fread( remark, 1, 30, fp );
fclose( fp );
treeview_artist->addArtistMember(author,title);
treeview_album->addAlbumMember(disc_name,title);
return true;
}
5.3.2 写代码时的思路依据
ID3标签只有128个字节。该标签的标签头必须是TAG。都是char字符指针类型。Title，Artist，Album分别是歌曲名、演唱者、专辑名称，均占30个字节。不足30个字节，则使用‘\0’补齐，出品年代占4字节。各项信息都是顺序存放，没有任何标识将其分开。
5.4 播放控制
播放控制中实现了播放（暂停）功能，上一首，下一首，停止，静音，音量调节。这些功能放在这个类里面，加入到主窗体时，涉及到的这些功能就可以进行单独控制，这些功能的实现复杂度差不多。
5.4.1 主要相关功能的部分代码
播放状态有三种。播放、暂停、停止。点击播放按钮的时候，可以播放音乐文件。点击暂停按钮，可以实现暂停播放音乐文件。点击停止按钮，可以停止播放音乐文件。
实现具体功能的时候，自定义了三个信号。状态初始化为播放状态。利用信号与槽机制，四个主体，发送者，发送信号，接收者，响应处理。发送者发射信号，响应部分若为信号，信号随即也被发射，就以点击stopButton为例，stopButton发射clicked（）信号，接收者播放控制的信号stop（）也随即发出，在主窗体部分，由播放控制发出的信号stop（）由QMediaPlayer的槽函数stop（）做出响应。点击播放按钮，发射clicked（）信号，接收者播放控制自定义槽函数playClicked（）做出相应的响应。代码如下。
歌曲控制中信号和槽函数的注册
connect(playButton,SIGNAL(clicked()),this,SLOT(playClicked()));
connect(stopButton,SIGNAL(clicked()),this,SIGNAL(stop()));
主窗体的信号和槽函数的注册
connect(player, SIGNAL(stateChanged(QMediaPlayer::State)),
controls, SLOT(setState(QMediaPlayer::State)));
connect(controls, SIGNAL(play()), player, SLOT(play()))；
connect(controls, SIGNAL(pause()), player, SLOT(pause()))；
connect(controls, SIGNAL(stop()), player, SLOT(stop()))；
设置播放状态的函数，代码如下。
void PlayerControls::setState(QMediaPlayer::State state)
{
if (state != playerState) {
playerState = state;
switch (state) {
//当前状态为停止状态
case QMediaPlayer::StoppedState:
//设置停止按钮不可用
stopButton->setEnabled(false);
//设置播放按钮图标为播放
playButton->setIcon(style()->standardIcon(QStyle::SP_MediaPlay));
break;
//当前状态为播放状态
case QMediaPlayer::PlayingState:
//设置停止按钮可用
stopButton->setEnabled(true);
//设置当前播放按钮的图标为暂停 playButton->setIcon(style()->standardIcon(QStyle::SP_MediaPause));
break;
//当前状态为暂停状态
case QMediaPlayer::PausedState:
//设置停止按钮可用
stopButton->setEnabled(true);
//设置当前播放按钮的图标为播放
playButton->setIcon(style()->standardIcon(QStyle::SP_MediaPlay));
break;
}
}
}
connect(playButton, SIGNAL(clicked()), this, SLOT(playClicked()))；
//点击播放按钮，切换状态
void PlayerControls::playClicked()
{
switch (playerState) {
case QMediaPlayer::StoppedState:
case QMediaPlayer::PausedState:
emit play();
break;
case QMediaPlayer::PlayingState:
emit pause();
break;
}
}
静音设置。playerMuted记录有声音还是静音这个状态。点击音量按钮，可以发射一个改变当前音量状态的信号。Control窗体通过操作这三个函数便可实现静音功能。具体代码如下：
//判断是否静音
bool PlayerControls::isMuted() const
{
return playerMuted;
}
//点击静音，切换状态
void PlayerControls::muteClicked()
{
emit changeMuting(!playerMuted);
}
//静音设置
void PlayerControls::setMuted(bool muted)
{
if (muted != playerMuted) {
playerMuted = muted;
muteButton->setIcon(style()->standardIcon(muted
? QStyle::SP_MediaVolumeMuted
: QStyle::SP_MediaVolume));
}
}
音量调节设置，拖动音量调节滑动条，可以改变音量。这个功能是利用QSlider实现的。QSlider类是一个抽象基类，这个类提供了一个区间内的整数值，有一个滑块，可以定位到一个整数期间的任意值。QSlider是最常见的音量控制或多媒体播放进度等滑块。Scroll Bar的属性，maximum、minimum分别用来设置最大、最小值；singleStep属性是每步的步长，默认是1。默认情况下，每移动一个刻度，都会发射valueChanged()信号,original是设置部件的方向，有水平和垂直两种选择。invertedAppearance属性设置滑块所在的位置，默认在最右端。
具体音量调节设置代码如下：
volumeSlider = new QSlider(Qt::Horizontal, this);
volumeSlider->setRange(0, 100);
音量设置的原理是：拉动volumeSlider发射sliderMoved(int)信号，接收者播放控制的信号changeVolume(int)也随即发出，在主窗体部分，播放控制发出的信号changeVolume(int)，由QMediaPlayer的槽函数SLOT(setVolume(int)做出响应。QMediaPlayer发出信号volumeChanged(int)，播放控制槽函数setVolume(int)做出响应。
connect(volumeSlider,SIGNAL(sliderMoved(int)),this,SIGNAL(changeVolume(int)));
connect(controls,SIGNAL(changeVolume(int)),player,SLOT(setVolume(int)));
connect(player,SIGNAL(volumeChanged(int)),controls,SLOT(setVolume(int)));
//获取音量大小值
int PlayerControls::volume() const
{
return volumeSlider ? volumeSlider->value() : 0;
}
//设置音量大小的值
void PlayerControls::setVolume(int volume)
{
if (volumeSlider)
volumeSlider->setValue(volume);
}
上一首，下一首，点击上一曲，就播放上一首歌曲，点击下一曲就播放下一首歌曲。在播放控制中设置两个信号。代码如下：
Signals：
void next();
void previous();
在播放控制中两个按钮的设置代码如下：
nextButton = new QToolButton(this);
nextButton->setIcon(style()->standardIcon(QStyle::SP_MediaSkipForward));
previousButton = new QToolButton(this);
previousButton->setIcon(style()->standardIcon(QStyle::SP_MediaSkipBackward));
上一首的实现原理是：点击previousButton，previousButton发射clicked（）信号，接收者播放控制的信号previous（）也随即发出，在主窗体部分，播放控制发出的信号previous（）由主窗体的槽函数previousClicked（）做出响应。
实现的代码如下：
connect(previousButton, SIGNAL(clicked()), this, SIGNAL(previous()));
connect(controls, SIGNAL(previous()), this, SLOT(previousClicked()));
//上一曲槽函数
void Widget::previousClicked()
{
if(player->position()<=5000)
playlist->previous();
else
player->setPosition(0);
}
下一首的实现原理是：点击nextButton，nextButton发射clicked（）信号，接收者播放控制的信号next（）也随即发出，在主窗体部分，播放控制发出的信号next（）由QMeidaplaylist的槽函数next（）做出响应。
实现的代码如下：
信号和槽函数
connect(nextButton, SIGNAL(clicked()), this, SIGNAL(next()));
connect(controls, SIGNAL(next()), playlist, SLOT(next()));
速率调节，在歌曲控制部分，利用下拉列表来实现。下拉列表就是一个框，添加了三个属性值，0.5x,1.0x,2.0x，利用setCurrentIndex设置当前显示的值为1.0x。该部分写了一个槽函数，这个槽函数，用于更新当前rateBox的显示值。主窗体也有一个相应的槽函数，改变当前播放的音频的播放速率。主窗体注册的槽函数改变播放速率，发出歌曲控制部分的自定义信号changeRate(qreal rate)，由MediaPlayer提供的槽函数设置播放速率，实现播放速率的改变。歌曲控制部分定义了三个函数qreal PlayerControls::playbackRate(),setPlaybackRate(floatrate),void PlayerControls::updateRate()。
速率调节界面如图5.4所示。
具体实现代码如下所示。
rateBox = new QComboBox(this);
rateBox->addItem("0.5x", QVariant(0.5));
rateBox->addItem("1.0x", QVariant(1.0));
rateBox->addItem("2.0x", QVariant(2.0));
rateBox->setCurrentIndex(1);
速率调节的实现原理是：选中rateBox的速率值，rateBox发射activated(int)信号，接收者播放控制的槽函数updateRate（）做出响应。在updateRate（）的函数中，主动发射了信号changeRate(playbackRate());在主窗体部分，播放控制发出的信号changeRate(playbackRate());在主窗体部分，播放控制发出的信号changeRate(playbackRate())由QMeidaplayer的槽函数setPlaybackRate(qreal)做出响应。
connect(rateBox,SIGNAL(activated(int)),SLOT(updateRate()));
connect(controls,SIGNAL(changeRate(qreal)),player,SLOT(setPlaybackRate(qreal)));
歌曲控制部分的三个函数的实现代码如下：
//获取当前播放快慢速率
qreal PlayerControls::playbackRate() const
{
//qreal是double类型
//itemDate的返回值是一个可存储的数据类型
return rateBox->itemData(rateBox->currentIndex()).toDouble();
}
//设置播放速率
void PlayerControls::setPlaybackRate(float rate)
{
for (int i = 0; i < rateBox->count(); ++i) {
if (qFuzzyCompare(rate, float(rateBox->itemData(i).toDouble()))) {
rateBox->setCurrentIndex(i);
return;
}
}
rateBox->addItem(QString("%1x").arg(rate), QVariant(rate));
rateBox->setCurrentIndex(rateBox->count() - 1);
}
//获取更新播放速率
void PlayerControls::updateRate()
{
emit changeRate(playbackRate());
}
5.4.2 媒体对象状态的简单介绍
Qt中媒体文件的播放划分为几个状态，媒体对象MediaObject总是处于这几种状态中的其中一个。这几种状态由QMediaPlayer：：MediaStatus枚举变量来定义。媒体对象可以在任意时间变化到任意的状态，而无论其先前处于什么状态，当媒体对象的状态发生改变时就会发射stateChanged()信号，可以通过关联该信号来获取媒体对象当前的状态，从而进行一些相关的设置，例如改变播放图标的状态等。
5.5 播放进度条
播放列表中加入了音频文件，音频文件开始播放，播放进度条有效。可以滑动播放进度条的位置，并且从滑动位置开始播放，从而实现快进快退。播放进度条右侧显示当前已播放时间和当前播放文件的总时间。
5.5.1 主要相关功能的部分代码
播放进度条，我们能够设计的界面就是利用QSLider实现播放进度条，利用labelDuration显示播放时间/总时间。它的初始化及布局界面如下。
播放进度条如图5.5所示。
//duration()当前播放的时间间隔
//Slider播放进度条
slider = new QSlider(Qt::Horizontal, this);
slider->setRange(0, player->duration() / 1000);
//labelDuration显示播放时间/总时间
labelDuration = new QLabel(this);
QHBoxLayout *hLayout = new QHBoxLayout;
hLayout->addWidget(slider);
hLayout->addWidget(labelDuration);
以下信号和槽函数的实现原理是：slider发射sliderMoved(int)信号，接收者Widget的槽函数seek（int）做出响应。在seek（int）函数中，player调用设置播放进度条位置的函数。这部分代码实现了播放音频文件时可以改变播放进度条的位置。
该部分代码如下：
connect(slider, SIGNAL(sliderMoved(int)), this, SLOT(seek(int)));
//实现滚动条槽函数
void Widget::seek(int seconds)
{
//设置播放条的位置
player->setPosition(seconds * 1000);
}
实时改变播放进度条的位置，player发射durationChanged（qint64）信号，接收者widget自定义槽函数durationChanged（qint64）用于响应信号，这样widget可以获取到总的播放时间。Player发射positionChanged（qint64）信号，接收者自定义槽函数positionChanged（qint64）用于响应信号，这样Widget可以获取到当前播放的时间。
这两个槽函数的注册及具体实现代码如下：
connect(player,SIGNAL(durationChanged(qint64)),this，SLOT(durationChanged(qint64)));
connect(player,SIGNAL(positionChanged(qint64)),this，SLOT(positionChanged(qint64)));
void Widget::durationChanged(qint64 duration)
{
//总时间
this->duration = duration/1000;
slider->setMaximum(duration / 1000);
}
void Widget::positionChanged(qint64 progress)
{
//当前播放时间
if(!slider->isSliderDown()) {
slider->setValue(progress / 1000);
}
updateDurationInfo(progress / 1000);
}
//更新时间标签上的值
void Widget::updateDurationInfo(qint64 currentInfo)
{
QString tStr;
if (currentInfo||duration){
QTime currentTime((currentInfo/3600)%60,(currentInfo/60)%60,currentInfo%60,(currentInfo*1000)%1000);
QTime totalTime((duration/3600)%60,(duration/60)%60,duration%60,(duration*1000)%1000);
QString format = "mm:ss";
if (duration > 3600)
format = "hh:mm:ss";
tStr = currentTime.toString(format) + " / " + totalTime.toString(format);
}
labelDuration->setText(tStr);
}
6 系统测试
6.1 测试的意义
系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案.。它的的任务是尽可能彻底的检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统“做得怎样？”。
6.2 测试方法
软件测试有两种方法：白盒法和黑盒法
如果知道了产品应该具有的功能，可以通过测试来检测是否每个功能都能实现，这种测试方法叫作黑盒测试法；如果知道产品的内部工作过程，可以通过测试来检验是否按照规格说明说的规定正常运行，这个方法叫白盒测试法。
对于软件而言，黑盒测试法是把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程。也就是说黑盒测试是在程序的接口进行测试，它只检查程序的功能是否按照规格说明说的说明正常运行，程序是否能恰当的接受输入数据，产生正确的输出信息，并且保持外部信息的完整性。黑盒测试又称为功能测试。与黑盒测试法相反，白盒测试法是把程序看成是装在一个透明的白盒子里。也就是完全了解程序的结构和处理过程，这种方法按照程序内部的逻辑测试程序，检验程序中的每条通路是否能按预定的要求正确工作，白盒测试又称为结构测试。
粗看起来，不论采用上述那种测试方法，只要对每一种可能的情况都进行测试，就可以得到完全正确的程序。包含所有可能情况的测试成为穷尽测试，对于实际程序而言，穷尽测试通常是不可能做到的。使用黑盒测试法为了做到穷尽测试，至少对所有输入数据的各种可能值的排列组合都进行测试，但是，由此得到的应该测试的情况，数字往往达到实际上根本无法测试的程度。实践表明，用无效的输入数据比有效的输入数据进行测试往往能发现更多的错误。使用白盒测试法和使用黑盒测试法一样也不可能做到穷尽测试。
因为不能做到穷尽测试，所以软件测试不可能发现程序中的所有错误。也就是所通过测试并不能证明程序是完全正确的。但是，我们的目的是要通过测试保证软件爱你的可靠性，因此，必须仔细设计测试方案，力争用尽可能少的测试发现尽可能多的错误。
6.3 测试过程
拟定测试计划。根据系统功能，仔细运行可能出现的状况，对各种情况进行汇总，然后拟定出一份具体的测试步骤。
初步测试。根据拟定好的计划进行调试，出现意外情况时及时记录。测试完后对所记录的意外情况进行分析，然后提出改进的方案，再进行修改。
深度测试。最后的修改确认没有漏洞后再进行测试，从各个方面进行一次整体的排查，直到不再出现意料之外的情况。
测试人员。测试初期阶段主要由编程人员进行测试，以便能够全面的进行错误排查。
6.4 单元测试
（1）测试一：将系统中的文件加入到播放列表时，是否可以加入到播放列表。
具体操作：点击open按钮，弹出文件对话框，选中的音频文件，单击确定。
结果：通过点击打开文件，选中的音频文件加入到播放列表。
结论：要求加入音频文件。
（2）测试二：选中的音频文件以艺术家分类。
具体操作：点击open按钮，弹出文件对话框，选中的音频文件，单击确定。
结果：第一步选中的音频文件以演唱者分类。
结论：可以加入。
（3）测试三：选中的音频文件以专辑名称分类。
具体操作：点击open按钮，弹出文件对话框，选中的音频文件，单击确定。
结果：第一步选中的音频文件以专辑名称分类。
结论：可以加入。
（4）测试：播放功能。
具体操作：选中播放列表中的音频文件，点击播放按钮。
结果：播放选中的音频文件。
结论：播放列表不为空。
（5）测试：暂停功能。
具体操作：点击暂停按钮。
结果：暂停播放音频文件。
结论：可以实现。
（6）测试：上一曲功能。
具体操作：点击上一曲。
结果：播放播放列表中的上一首歌曲
结论：播放列表中当前播放的音频文件之前有其他音频文件。
（7）测试：下一曲功能。
具体操作：点击下一曲。
结果：播放播放列表中的下一首音频文件。
结论：播放列表中足够多的音频文件。
（8）测试：停止功能。
具体操作：点击停止按钮
结果：停止播放音频文件，播放进度条归起点。
结论：播放状态可以停止。
6.5 测试总结
本系统的各个功能现已基本实现，代码基本无误。但，通过对本系统的测试发现，该系统仍然存在一些细节问题。例如，有些地方的设计还是不够人性化。这些问题主要还是由于对系统开发缺乏经验，以后会继续努力。
结论
本文主要介绍了基于Qt的音频管理系统的设计与实现。系统实现了以下功能：
以演唱者分类管理音乐文件，系统可以根据打开的文件自动按照演唱者分类加入该演唱者对应的歌曲名。
以专辑名称分类管理音乐文件，系统可以根据打开的文件自动按照专辑名称分类加入该专辑对应的歌曲名。
可以控制音频文件的播放，暂停播放，停止播放。
拖动音量滑动条，实现音量高低控制。
点击音量图标，实现静音。
拖动播放进度条，实现快进等。
本系统是一个具有实际意义的系统。它可以在Windows7，Ubuntu上运行。实际应用表明，本系统使用方便，执行效率较高。基本能够达到预期的效果。
参考文献
[1] 曹静，软件开发生命周期与统一建模语言UML[M].北京：中国水利水电出版社，2008.
[2] 汪永好，周延森，基于嵌入式Linux的播放器的设计与实现[J],计算机工程与设计，2009,30
（17）.
[3] 焦正才，樊文侠，基于Qt/Embedded 的MP3音乐播放器的设计与实现[J],电子设计工程，2012,20
（7）.
[4] 陈自龙，周书杰，唐永明，基于ARM嵌入式系统的高保真无损音乐播放器设计[J],电子器件，
2012,35（6）.
[5] Donald E.kunth,the art of Computer Programming[M]，Zoroth printing，2002.
[6] Erich Gamma,Ralph J,等,Design Pattern[M],Addison-Wesley Professional,1995.
[7] Barbara E.Moo,Stanley B.Lippman 等,C++ Primer中文版[M].北京：人民邮电出版社，2006.
[8] BjarneStroustrup，The Design and Evolution of C++[M],Addison-Wesley Professional,1994.
[9] 成洁，卢紫毅,Linux窗口程序设计-QT精彩实例分析[M].北京：清华大学出版社，2008.
[10] Scott Meyers,More Effective C++[M].北京：机械工业出版社，2006.
[11] Blanchette J ,Summerfield M. C++ GUI Programming with Qt4,Second Edition[M]. USA:
Prentice Hall, 2006.
致谢
经过一段时间的不懈努力，我的毕业设计终于结束了。毕业设计的结束也标志着大学生活的完结。经过了大学的洗礼，我发现自己成熟了许多，长大了许多。这不仅体现在学习上的进步，还表现在思想上的改变。总之，对我来说是收益良多。大学事关真的是我人生最宝贵的财富。这一切的一切和大家对我的支持和帮助是分不开的。这次毕业设计老师对我的帮助真的是非常多。在这次拿到毕业设计题目，不知道如何设计及列出功能，写开题报告，从设计环节到实现环节，到论文中的具体问题，严格把关，循循善诱，在此我表示衷心感谢！同时我还要感谢在我学习期间给我极大帮助的各位老师以及关心我的同学和朋友！最后，我最应该感谢的还是我的母校，太原理工大学，大四一年，离家千里，我成长了好多，也学到了好多知识。让我意识到在社会中，我所要承担的。更加感谢的是学校，学校给我提供了的优秀的学习生活环境，让我快乐的成长、学习，真的很感谢。
特别感谢冯秀芳老师在毕业设计工作中给予我的帮助！
外文原文
Forensic analysis of video file formats
abstract
Video file format standards define only a limited number of mandatory features and leave room for interpretation. Design decisions of device manufacturers and software vendors are thus a fruitful resource for forensic video authentication. This paper explores AVI and MP4-like video streams of mobile phones and digital cameras in detail.We use customized parsers to extract all file format structures of videos from overall 19 digital camera models,14 mobile phone models, and 6 video editing toolboxes. We report considerable differences in the choice of container formats, audio and video compression algorithms,acquisition parameters, and internal file structure. In combination, such characteristics can help to authenticate digital video files in forensic settings by distinguishing between original and post-processed videos, verifying the purported source of a file, or identifying the true acquisition device model or the processing software used for video processing.
2014 The Authors. Published by Elsevier Ltd on behalf of DFRWS. This is an open access article under the CC BY-NC-ND license.
Keywords:Digital forensics; File format; Metadata; Video; Authentication;
Introduction
Methods to verify the authenticity of media data are of growing relevance in our digital world. While most consumer devices lack practical authentication support at all, attacks against professional camera authentication systems have demonstrated weaknesses of existing in-device solutions.Forensic techniques to infer the provenance and the processing history of media files ex post have thus gained more and more interest among researchers and practitioners. Forensic image analysis has been the main driver of the field (Sencar and Memon, 2013), but also video files have recently been brought to the forefront (Milani et al.,2012b). Resembling the evolution of digital image forensics,an already ample body of literature approaches the problem of video forensics through the analysis of inherent device characteristics or processing artifacts in the video data (Chen et al., 2007; Wang and Farid, 2007; Hsu et al.,
2008; Conotter et al., 2011; Stamm et al., 2012; Vázquez-Padín et al., 2012, amongst others).
File format information and metadata are another source of forensic evidence, but have generally received less attention. Existing works mainly focus on digital images.Here, basic JPEG (ISO/IEC 10918-1, ITU-T Recommendation T.81, 1992) and EXIF (Japan Electronics and Information Technology Industries Association, 2002) metadata properties have gained major interest. Digital cameras and image processing software (or groups thereof) use customized.
quantization tables. Differences therein can narrow down the source device of a questioned image (Farid, 2008;Kornblum, 2008). Characteristics of thumbnail images(often saved as JPEG images themselves) have been reported to be another pool of forensically relevant features(Murdoch and Dornseif, 2004; Kee and Farid, 2010). In one of the most elaborate approaches, Kee et al. (2011) combine image and thumbnail compression parameters, image and thumbnail dimensions and the number of EXIF entries into signatures of camera model or processing software configurations.
By testing against a reference database, images of unknown or uncertain provenance can be attributed to a class of source configurations. Images are flagged as suspicious if no match is found. In a different approach, Fan et al.(2013) exploit noise characteristics to determine whether image content and EXIF data are consistent. However, as tampering with compression parameters or EXIF entries is only a question of using proper software tools (which are often publicly available), concerns have frequently been expressed that high-level file format information and metadata are easily replaceable and/or forgeable (Sencar and Memon, 2008). On the contrary, existing image processing software and metadata editors do not allow users to access or to modify core file structures. Along these lines, Gloe(2012) reports that peculiarities in the specific internal order of JPEG and EXIF structures are particularly valuable and distinctive information for digital image authentication. Such low-level characteristics thus offer a much increased reliability and relaxdto some degreedthe common assumption that file format and metadata information shall not be trusted perse.
Following this trail, this paper extends the idea of file format forensics to popular digital video data container formats, for whichdto the best of our knowledgedno systematic exploration of file format and/or metadata specifics has been reported in the forensic literature so far.Similar to differences in the JPEG file structure, we identify manufacturer- and model-specific video file format characteristics and point to traces left by processing software. Such traces can be used to authenticate digital video streams and to attribute recordings of unknown or questionable provenance to (groups of) video camera models. Note that this differs from video file carving (Pal and Memon, 2009; Lewis, 2012), where it is usually sufficient to find valid video streams in (fragmented) mass storage dumps. Based on a description of our (Test setup) and (General observations) on video file format forensics, the following sections demonstrate that peculiarities of the(AVI Container format), of (Quicktime and related container formats (MP4, 3GP)), and of (MJPEG Compression parameters) can yield important insights about provenance and processing history of digital videos. The paper closes with a (Summary and concluding remarks).
Test setup
We report findings from the examination of each one device of overall 19 digital camera models and 14 mobile phone models, all of them equipped with video capturing functionality. We acquired 3 to 14 videos per device by iterating over all available video quality settings (e.g., frame size and frame rate). Mobile phones were also switched between regular and MMS (Multimedia Message Service)mode where available. All devices were subject to slight motion during the video capturing process. Table 1 summarizes our test setup.
For a selected number of camera models, video editing software was used to cut short sequences (length: 10 s) from the recorded video streams. All software in our tests supports non-intrusive (‘lossless’) video editing, i.e., we saved files without re-compressing the original stream.Hence, the edited videos are presumably not detectable by means of double compression artifacts (Wang and Farid,2006; Milani et al., 2012a). The ‘Adobe Premiere’ toolbox was a sole exception in our test set in this regard. The commercial software is one of the major professional video editing tools, but does not support lossless processing.
We have written our own customized file parser(s) to read and extract all available file format information and metadata from the videos in our database.2 As it is impossible to detail all model- or vendor-specific singularities within the scope of this paper, the following sections focus on selected results and observations that we believe are particularly relevant for practical forensic analyses of common video container formats.
General observations
The majority of digital cameras in our database stores videos in the AVI container format. Only a few of the test devices use Apple Quicktime MOV containers. We found that most digital cameras compress video data using Motion JPEG (MJPEG), where every video frame is handled as independently JPEG-compressed image. Only three camera models in our sample use more sophisticated and efficient compression algorithms (DivX, Xvid or H.264).Before compression, frames are generally converted to the YUV color space. We encountered 4:2:2 and 4:2:0 subsampling to reduce the resolution of chroma channels.MJPEG compressed video streams utilize the full intensity range of 256 intensity levels for 8-bit encoded frames (yuvj422p or yuvj420p), whereas camera models with DivX or Xvid support (yuv420p) use only a reduced number of 220/225 intensity levels for the luminance/chrominance channel(s) (ITU-R Recommendation BT.601-7, 2011). Audio data in the video container is usually stored as raw data (PCM), using linear (8-/16-bit) or logarithmic (m-law) quantization.
All mobile phones in our database store video data in MOV-based container formats (MOV, 3GP, MP4). The LG KU990 camera phone is an exception and also supports AVI containers. Interestingly, none of the mobile phones uses MJPEG compression. Instead, more sophisticated compression algorithms find application, e.g,H.263,
H.264, MPEG-4 video (simple profile) or DivX. Subsampling always follows a 4:2:0 scheme. In contrast to videos from digital cameras, the audio track of mobile phone videos is typically also subject to lossy compression. We found MPEG-based audio compression or the Adaptive Multi-Rate audio codec (AMR-NB) to be most common. The latter is a standard optimized for speech coding (3rd Generation Partnership Project, 1999), which is very common in mobile phones designed for GSM- and UMTS-networks.
AVI Container format
Microsoft introduced AVI (Audio Video Interleave) in 1992 as a multimedia container format, which can contain both video and audio streams (Microsoft DeveloperNetwork).
General file structure
AVI files start with a mandatory AVI RIFF (Resource Interchange File Format) header. All following data is organized and stored in so-called lists and chunks. A four character code (FourCC) is used to identify these data segments.The FourCC for a list is LIST. Different FourCC’s exist for chunks, e.g., JUNK or idx1. There is no strict specification that defines the sequence and occurrence of lists and chunks.
Fig. 1 illustrates the basic file structure that we found to appear similarly in all examined AVI files captured by digital cameras or mobile phones. All devices store the mandatory list hdrl directly after the AVI RIFF header. This list segment comprises all the information that is necessary to decompress the video and audio data stored in the file. The third mandatory AVI segment after header and hdrl list is the movi list. It contains the actual video and audio data. Depending on the specific camera or phone model, additional lists and/or JUNK chunks may exist between the hdrl and movi lists. These optional data segments are either used for padding or to store metadata. The idx1 chunk indexes the data chunks and their location in the file. It is mentioned as an optional element in the AVI file reference (Microsoft Developer Network, 0000), yet we found it in all video files in our database.
Camera model specifics
An inspection of our video database revealed considerable differences between device models and software vendors, a selection of which we discuss in the following.These and related characteristics can be tested for to verify or to infer the source of questioned video content.
Fig. 2 exemplarily illustrates four typical AVI file structures of video recordings from Canon A640, Canon S45,Nikon CoolPix S3300, and Ricoh GX100 digital cameras. The tree-like representations reflect the nested character of the Internal structure of AVI files acquired with our cameras.
Fig. 2. AVI file structure of videos acquired with Canon A640, Canon S45, Nikon CoolPixS3300, and Ricoh GX100 digital cameras. Equivalent elements are arranged on the same horizontal level. Not all nested sub-elements are listed..
AVI container format and depict all major lists and chunks in accordance to their actual order in the respective files.Corresponding elements are arranged on the same horizontal level. The figure indicates that not all files share the same components, and that both the content and the format of specific chunks may vary. The Nikon camera, for instance, does not use the IDIT chunk to store the recording date, but adds a dedicated ncdt list to organize its metadata. All four cameras insert an INFO list with distinct content after the stream header. The two Canon cameras further differ in the format of the IDIT date specification, but none of them uses the same format as the Ricoh GX100.
We also found that digital cameras with MJPEG compression may specify the video codec in lowercase or uppercase letters. Canon Ixus IIs, Canon PowerShot (A640,S45, S70), Nikon CoolPix, Optio W60, Ricoh GX100, and CASIO EX-M2 cameras use ‘mjpg’, whereas all other tested cameras prefer the string ‘MJPG’. Further variations exist in the hdrl list. The Agfa Sensor505-X camera adds an additional stream description that refers to the VendorName.The Pentax Optio A40 camera explicitly specifies the StreamName (‘Video’ or ‘Audio’). Video and audio stream descriptions in hdrl lists from LG KU990 mobile phones are followed by JUNK chunks. Similar to the examples in Fig. 2, most camera models add their own INFO list after the hdrl list to provide additional metadata. Also here, padding with JUNK data chunks is common.
Video editing
All software tools in our test setting leave distinct traces in the file structure of edited AVI videos, which do not match any of the camera characteristics in our database.Even losslessly edited videos are thus detectable by comparing the file structure of a questioned file with a reference of the purported source.
Fig. 3 gives two specific examples. The familiar tree-like graphs depict AVI file structures of a Canon A640 video after editing with the tools AVIDemux and VirtualDub, respectively. Differences to the structure of the original file (shown in the leftmost part of Fig. 2) are printed on gray background. Observe that both tools place JUNK chunks in the hdrl list at the end of audio and video stream and VirtualDub. Equivalent elements are arranged on the same horizontal level. Not all nested sub-elements are listed. Differences to the original file are printed on gray background (see also Fig. 2)descriptions. VirtualDub adds another LIST with OpenDML3 AVI header data. The same tool extends the toplevel file hierarchy by its own identifier JUNK chunk(‘VirtualDub build 32842/release’). AVIDemux changes the video codec information to capitalized letters.
Other editing softwares leave their own traces. FFmpeg, for instance, also inserts additional JUNK chunks. The content of these entries is fixed and specific to FFmpeg. In addition, a list info with details about the employed encoder software and version (here Lavf54.59.106) is present in videos edited with FFmpeg.
Metadata lists and JUNK chunks that would hint to the recording device are typically lost in edited files. Virtual-Dub is an exception and appends the device-specific INFO list of the original file to the edited video (cf. Fig. 3).In general, however, losslessly edited video streams might still contain distinct compression characteristics of the source camera, as we will discuss in the section on (MJPEG Compression parameters).
QuickTime and related container formats (MP4, 3GP)
The MOV container format was introduced by Apple for its QuickTime multimedia framework in 1991. It was later used as a basis for the MP4 and 3GP container specifications (Apple Computer, Inc., 2001; ISO/IEC 14496, 2003; 3rd Generation Partnership Project, 2004). For the sake of simplicity, we refer to all three container formats as MP4-like formats.
General file structure
Similar to the AVI format, MP4-like containers consist of individual data structures (‘atoms’ or ‘boxes’), which are identified via unique 4-byte sequences. Information about the atom size precedes the corresponding identifier. Atoms can be nested. Although the format explicitly does not define any particular order or number of data segments, we found the general structure in Fig. 4 to be present in most of the examined files. MP4-like video files usually start with the ftyp atom, which refers to the file type specifications the file is compatible with.4 The actual data streamis stored in the mdat atom, which is accompanied by corresponding metadata in the moov atom.We also encountered files with moof atoms, which contain shorter data chunks of elementary streams.
Camera model specifics
Reflecting the by far more complex file format, MP4-like videos exhibit an even larger degree of source-dependent internal variations than AVI files.5 This is only to the advantage of forensic investigators, who will find these characteristics useful for authentication purposes. Yet it is beyond the scope of this paper to detail all the differences
we observed, and we rather focus on select indicative examples.
Most MP4-like videos in our database start with the ftyp atom, yet we also found a number of exceptions. Kodak videos, for instance, start with a skip atom, whereas Minolta Z1 videos place a pnot atom with a reference to previewdata at the beginning of a file. The Praktica DC2070 camera does not use a header at all and starts with the mdat atom directly. As MP4-like container formats are compatible with a plethora of different data formats,codecs and parameterizations, the ftyp atom-if presentdstates which specification is the ‘best use’ of the file in the major_brand field. Additional fields then list the minor version and compatible brands. Table 2 reports combinations of ftyp major and compatible brand specifications in our database. It indicates that these specifications can differ to a large degree between different recording devices. We do not report the minor_version field,as we usually found it set to 0.Values stored in the MP4 moov atom time_scale field, as observed by iterating over all available quality settings per device. Symbol ‘.’ indicates that mvhd and mdhd entries do not differ.
The moov atom is one of the most complex data structures in MP4-like files. It specifies the decoding parameters for parsing the mdat data stream correctly. The atomitself is organized in a number of sub-structures, such as the general mvhd movie header atom or the more specific mdhd media header atom. We found that parameter settings largely depend on the specific camera model. Table 3 exemplarily summarizes settings for the time_scale field, which controls both frame rate and audio sampling rate. Observe that mvhd and mdhd atom may define different values for this field, and that corresponding combinations thereof vary between different recording devices.
Besides the (quasi-)standard ftyp, mdat and moov atoms, we also encountered a variety of additional elements in MP4-like video files. The overview in Tab. 4 indicates, for instance, that some sources store metadata in udta user data atoms, or use free atoms for padding. Because the specific order of atoms is generally not explicitly defined, it is finally not surprising that there exist differences here, too. Notable deviations are Benq S88 and Nokia X3-00 videos. The former follow a ftyp moov mdat sequence (and optionally multiple subsequent pairs of moof mdat). The latter are organized as ftyp moov free mdat free.6 Motorola MileStone exhibit another interesting peculiarity. Here, the audio stream precedes the video stream.
Video editing
Like in the case of AVI editing, none of the MP4-like files produced by editing software in our test set is compatible with any recording device in our database. The three bottommost rows in Tables 2–4 exemplify some of the differences for FFmpeg, YAMB, and Adobe Premiere CS5. Observe that each software has its own unique signature,which emphasizes the usefulness of such characteristics in authentication scenarios.
Table 2 suggests that the combination and order of major and compatible brands is particularly indicative. The inspection of the time_scale field revealed that FFmpeg,AVIDemux and FreeVideoDub always set the mvhd value to 1000, with a mdhd (video) value depending on the original frame rate. Other tools employ different specifications(cf. Table 3). Table 4 indicates that Samsung SGH-D600 videos share the existence of additional iods object descriptor atoms with edited YAMB and Adobe Premiere videos, whereas the latter two also use extra tref and uuid atoms, respectively. FFmpeg-based software is the only one in our test set that adds an edts edit list atom to the file. We further observed that AVIDemux sets the acquisition time and modification time of edited files incorrectly to 01-01-1904.
MJPEG Compression parameters
Independent of the supported container format, the majority of digital cameras in our database uses Motion JPEG (MJPEG) to encode recorded videos (cf. Table 1). Individual MJPEG frames are stored as JPEG compressed still images, which itself consist of marker segments. Such The total number of unique tables is not the sum of unique tables per camera model.
segments are internally identified by 2-byte numbers,usually abbreviated with character sequences known from the JPEG standard(cf. Tab. 5). Based on our prior work on JPEG file forensics (Gloe, 2012), we expect that the existence and the order of specific segments here depends on the recording device, too.
For all MJPEG videos in our test set, we observed the same sequence of JPEG marker segments for all frames of one video. Differences do exist between groups of camera models. Within these groups, the sequence of JPEG marker segments is independent of respective quantization settings.Table 6 summarizes our findings for cameras with MJPEG support and the corresponding thumbnails(if available). Interestingly, MJPEG frames do not strictly follow the JFIF (Hamilton, 1992) or JPEG/Exif (Japan Electronics and Information Technology Industries Association, 2002) standards. Most cameras identify JPEG frames by means of an AVI application data segment(APP0(AVI1)) instead. Also the selection of JPEG marker segmentsdand in some cases even their sequencedis different from the JPEG still images of the same digital Camera.
Kodak M1063 video frames, for instance, contain a combination of AVI and JFIF application data segments,whereas the Praktica DC2070 digital camera uses a specific APP1(0x0000 mjpg) marker segment. Differences also exist in the organization of Huffman and quantization tables.Older Canon camera models (S45, S70, Ixus IIs) use the APP2 marker instead of the dedicated DHT marker segment to store the Huffman tables for entropy coding. Canon A640, Casio EX-M2, and Ricoh GX-100 video frames rely on standardized Huffman tables and do not store tables along with the frames. On the contrary, Kodak M1063 and Minolta Z1 cameras employ four DHT marker segments, i. e.,one segment per Huffman table instead of a single DHT segment with all four tables. The same camera models use two DQT segments instead of one to store the two required quantization tables. Another characteristic of Minolta videos are padding bits between subsequent frames.
It is also interesting to note that we identified the impressive number of 2914 unique JPEG quantization tables(luminance only) in our relatively small set of test videos.We refer to Table 7 for an overview. This large amount can be mainly attributed to cameras with scene-dependent adaptive quantization settings. We found that these cameras may also switch quantization tables between frames of the same video. Backed with similar experiences with adaptive quantization tables of thumbnail images in the Dresden Image Database (Gloe, 2012), our observations for MJPEG video frames strongly emphasize the challenges that forensic investigators have to deal with when attempting to create a comprehensive database of quantization Parameters.
We close this section with the remark that marker segment characteristics (and quantization tables) are most useful to verify or to determine the source device of an MJPEG video (or a group of devices). Lossless video editing does not modify the internal structure of MJPEG frames. This is different from the analysis of JPEG files, where we reported software-specific traces in the file structure of processed images (Gloe, 2012). At the same time, however, any video editing software is likely to change the structure of the container format in its very own specific way. It is thus still possible to detect lossless video editing based on file structure information, cf. our discussion of (Camera model specifics) of the AVI container format.
Summary and concluding remarks
This paper has presented a first systematic exploration of popular video container formats from a forensic viewpoint.Specifically, we have focused on the internal file structure of AVI and MP4-like (MOV, 3GP, MP4) multimedia containers. Our examination of videos from 19 digital cameras, 14 mobile phones, and various video editing tools indicate a profusion of model- and software-specific peculiarities.
The identified characteristics complement the toolbox of forensic investigators and provide valuable clues to verify the authenticity of digital video streams.
Our main findings can be summarized as follows:Videos from digital cameras and mobile phones often employ different container formats and compression codecs. Mobile phones opt for sophisticated compression algorithms (MP4V, H.26x). Most digital cameras in our test set prefer a combination of AVI containers and basic MJPEG compression.
The structure of AVI and MP4-like containers is not strictly defined. We observed considerable differences both in the order and in the presence of individual data segments.AVI files often contain specific INFO lists or JUNK chunks. MP4-like files may employ various nonstandard atoms and different parametrizations of specific atom entries.
Different camera models implement different JPEG marker segment sequences for MJPEG-compressed video frames. Content-adaptive quantization tables seem to be more frequent than for JPEG images. MJPEG frame and JPEG still image marker sequences and compression settings of the same camera model can be completely disjoint.
Loss less video editing leaves compression settings of the original video stream untouched, but introduces its very own distinctive artifacts in the structure of container files. While file format peculiarities of the genuine source device are typically lost after video editing, all tested software tools have unique file format signatures throughout our test set.
We note that our test set did not comprise multiple devices per camera model, so we can only surmise that our observations generalize to arbitrary devices of the same model as well. Yet this is to be expected, as our observations resemble similar reports about the structure of JPEG still images (Kee et al., 2011; Gloe, 2012), RAW image formats(Kalms et al., 2012), and MP3 audio files (Böhme and Westfeld, 2005). Because our analysis relies on file structure internals, we are currently not aware of any publicly available software that would allow users to consistently forge such information without advanced programming skills. This makes the creation of plausible forgeries undoubtedly a highly non-trivial undertaking and thereby reemphasizes that file characteristics and metadata must not be dismissed as unreliable source of evidence for the purpose of file authentication perse.
We note that further examinations will have to show how distinctive video file format characteristics are on a larger scale. It is without question that the identified general differences between different recording devices and editing softwares could also be combined with a signaturebased quantitative approach as proposed by Kee et al.(2011) for JPEG files. From the viewpoint of practical casework,however,we believe that such “condensed” signatures are never optimal, as they do not exploit all available information. This is particularly so when we consider that video container formats are by far more complex (and less strictly defined) than the JPEG format. At the same time, it is an open question how a more holistic signature would scale with all the unknown file format variations that doubtlessly still exist in the wild, but also to what degree modern streamlined smartphone designs are built around standard open source or vendor-based reference implementations.We can only surmise that a collection of source-specific file parsers, which mimic the careful manual inspection of a forensic investigator, could help in authentication scenarios. Future work will have to investigate how the specification of such parsers can be automated and how practical this approach is also for largescale source identification applications.
References
[1] 3rd Generation Partnership Project. Mandatory speech CODEC speech processing functions; AMR speech codec; General description, 3GPP TS 26.071; 1999.
[2] 3rd Generation Partnership Project. Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP), 3GPP TS26.244; 2004.
[3] Apple Computer, Inc. Quicktime file format; 2001.
[4] Böhme R,Westfeld A. Feature-based encoder classification of compressed audio streams. Multimed Syst 2005;11:108–20.
[5] Chen M, Fridrich J, Goljan M, Lukás J. Source digital camcorder identification using sensor photo-response non-uniformity. In: Delp EJ,Wong PW, editors. Proceedings of SPIE: Security andWatermarking of Multimedia Content IX. SPIE Press; 2007. 65051G.
[6] Conotter V, O’Brien J, Farid H. Exposing digital forgeries in ballistic motion.IEEE TransInfForensics Security 2011;7:283–96.
[7] Fan J, Cao H, Kot AC. Estimating EXIF parameters based on noise features for image manipulation detection. IEEE Trans Inf Forensics Security 2013;8:608–18.
[8] Farid H. Digital image ballistics from JPEG quantization: a followup study[Technical Report TR2008–638]. Hanover, NH, USA: Department of Computer Science, Dartmouth College; 2008.
[9] Gloe T. Forensic analysis of ordered data structures on the example of JPEG files. In: IEEE international Workshop on Information Forensics and Security (WIFS). IEEE; 2012. pp. 139–44. Hamilton E. JPEG file interchange format, Version 1.02; 1992.
[10] Hsu CC, Hung TY, Lin CW, Hsu CT. Video forgery detection using correlation of noise residue. In: IEEE workshop on Multimedia Signal Processing (MMSP). IEEE; 2008. pp. 170–4.ISO/IEC 10918-1, ITU-T Recommendation T.81. Information technology.
[11] Digital compression and coding of continuous-tone still images;1992.ISO/IEC 14496. Information technology.coding of audio-visual objects,Part 14: MP4 file format; 2003.
[12] ISO/IEC 14496. Information technology. Coding of audio-visual objects,Part 12: ISO base media file format. 3rd ed. 2008.
[13] ITU-R Recommendation BT.601-7. Studio encoding parameters of digital television for standard 4:3 and wide-screen 16:9 aspect ratio; 2011.Japan Electronics and Information Technology Industries Association.JEITA CP-3451, Exchangeable image file format for digital still cameras:Exif version 2.2; 2002.
[14] Kalms M, Gloe T, Laing C. File forensics for raw camera image formats. In:6th Conference on Software, Knowledge, Information Management and Applications (SKIMA); 2012.
[15] Kee E, Farid H. Digital image authentication from thumbnails. In:Memon ND, Dittmann J, Alattar AM, Delp EJ, editors. Proceedings of SPIE: Media Forensics and Security II; SPIE Press; 2010. 75410E.
[16] Kee E, JohnsonMK, Farid H. Digital image authentication from JPEG headers.IEEE Trans Inf Forensics Security 2011;6:1066–75.
[17] Kornblum JD. Using JPEG quantization tables to identify imagery processed by software. Digit Investig 2008;5:S21–5.Lewis AB. Reconstructing compressed photo and video data [Technical Report UCAM-CL-TR-813]. Cambridge, United Kingdom: University of Cambridge, Computer Laboratory; 2012.Microsoft Developer Network. AVI RIFF file reference.
[18] http://msdn.microsoft.com/en-us/library/ms779636(VS.85).aspx.
[19] Milani S, Bestagini P, Tagliasacchi M, Tubaro S. Multiple compression detection for video sequences. In: IEEE International Workshop on Multimedia Signal Processing (MMSP); 2012a. pp. 112–7.
[20] Milani S, Fontani M, Bestagini P, Barni M, Piva A, Tagliasacchi M, et al. An overview on video forensics. APSIPA Transactions Signal Information Process 2012b;1:e2.
[21] Murdoch SJ, Dornseif M. Hidden data in internet published documents.In: 21st Chaos communication congress; 2004.
[22] Pal A, Memon N. The evolution of file carving. IEEE Signal Process Mag 2009;26:59–71.
[23] Sencar HT, Memon N. Overview of state-of-the-art in digital image forensics.In: Bhattacharya BB, Sur-Kolay S, Nandy SC, Bagchi A, editors.Algorithms, architectures and information systems security.
[24] Statistical Science and Interdisciplinary Research, vol. 3. World Scientific Press; 2008. pp. 325–48 [chapter 15].Sencar HT, Memon N, editors. Digital image forensics. Springer; 2013.
[25] Stamm MC, Lin WS, Liu KJR. Temporal forensics and anti-forensics for motion compensated video. IEEE Trans Inf Forensics Security 2012;7:1315–29.
[26] Vázquez-Padín D, Fontani M, Bianchi T, Comesaña P, Piva A, Barni M.Detection of video double encoding with GOP size estimation. In:IEEE international Workshop on Information Forensics and Security(WIFS). IEEE; 2012. pp. 151–6.
[27] Wang W, Farid H. Exposing digital forgeries in video by detecting double MPEG compression. In: ACM workshop on multimedia and security. ACM Press; 2006. pp. 37–47.
[28] Wang W, Farid H. Exposing digital forgeries in interlaced and deinterlaced video. IEEE Trans Inf Forensics Security 2007;2:438–49.
外文翻译
视频文件格式法医取证分析
托马斯.格，安德烈·菲舍尔，马蒂亚斯·基什内尔
研究公司，德累斯顿，德国
明斯特大学，信息系统部门，明斯特,德国
摘要
视频文件格式标准只是定义了有限数量的强制特性并留下了解释的余地。对视频法医认证来说，设备制造商和软件供应商的设计决策是卓有成效的资源。本文详细地探讨了AVI、类似MP4的移动手机视频流和数码相机。我们使用自定义的解析器来提取视频的所有文件格式结构，视频来自全部19个数码相机型号，14个手机型号，和6个视频编辑工具箱。我们报道了在选择容器格式,音频和视频压缩算法,采集参数,和内部文件结构，相当大的差异。在组合中，这些特性可以帮助验证数字视频文件在法医设置中通过区分原始视频和后期处理，验证所谓的文件来源，或识别真正的采集装置模型或处理软件，用于视频处理。
关键词：数字取证；文件格式；元数据；视频；认证
引言
验证媒体数据真实性的方法在我们的数字世界有不断增长的相关性。虽然大多数电子设备消费者完全缺乏实际验证支持，针对专业相机认证系统的攻击已经证明设备解决方案存在的弱点。可以推断出处和媒体文件事后处理历史的法医技术已经吸引了越来越多的研究者和实践者。法医图像分析一直是该领域的主要驱动力，而且视频文件最近也处于前沿。类似的数字图像取证的演进，已经足够大量的文学接近视频取证问题，通过固有的设备特性或视频数据加工工件的分析。
文件格式信息和元数据是法医物证的另一个来源，但普遍受到很少的关注。现有的作品主要集中在数字图像。在这里，基本的JPEG和EXIF（日本电子信息技术产业协会，2002）元数据属性已经获得了极大的兴趣。数码相机和图像处理软件（或它们的组合）使用自定义的量化表。其中的差异可以缩小质疑图像的源装置。缩略图图像的特征（通常保存为JPEG图像本身）已被报道成为法医取证相关特征的另一个备用方法。在最复杂的方法之一，组合图像和缩略图压缩参数，图像和缩略图的尺寸和进入相机模式签名或处理软件配置的EXIF条目数。通过测试一个参考数据库，未知或不确定出处的图像可以归结为一类源配置。如果没有找到匹配的，图像被标记为可疑。用一种不同的方法，利用噪声特性来确定是否图像内容和EXIF数据一致。然而，作为篡改压缩参数或EXIF条目只是使用适当的软件工具的问题（这往往是公开的），关心的问题已经多次地表明为高层次的文件格式信息和元数据，很容易更换和/或伪造。与此相反，现有的图像处理软件和元数据的编辑器不允许用户访问或修改核心文件结构。沿着这些方法，Gloe（2012）报告说，在JPEG特定的内部秩序和EXIF结构是特别有价值和进行数字图像认证特色的信息。这种低层次的特点从而提供一个增加的可靠性和放松，在一定程度上，常见的假设，即文件格式和元数据信息不应该是可信任的深灰色。
根据这一线索，本文扩展了文件格式取证的想法到流行的数字视频数据容器格式，因为，据我们所知，文件格式没有系统的探索和/或元数据的细节到目前为止已经在法医学文献有所报道。类似于JPEG文件结构的差异，我们确定了制造商和模型专用的视频文件格式特点和通过处理软件留下的点到痕迹。这些痕迹，可用于验证数字视频流和把未知或可疑的源记录归因于视频摄像机模型（组）。请注意，这不同于视频文件雕刻，通常足以找到有效的视频流在（成碎片的）大容量存储垃圾站。根据我们（测试设置）和（概述）关于视频文件格式取证的描述，下面的部分证明（AVI容器格式），（Quicktime及相关容器格式（MP4 ，3GP）），和（MJPEG压缩参数）的特殊性可以产生关于数字视频出处和处理历史的重要见解。
测试设置
我们报道了关于来自全部19个数码相机模型和14个手机模型的每一个设备检查结果的发现，它们都配备了视频捕捉功能。我们获得了3-14视频/每台设备，通过反复重复所有可用的视频质量设置（例如，帧大小和帧速率）。手机也在常规和可用的MMS（多媒体信息服务）模式之间切换。在视频捕获过程中，所有设备都受到轻微的运动。表1总结了我们的测试设置。
表1数码相机，手机和研究中使用的视频编辑软件
对于选定的大量相机型号，视频编辑软件是用来切来自记录的视频流的短序列（长度：10s）。在我们的测试中的所有软件支持无损伤（“无损”）的视频编辑，即我们保存文件不重新压缩原始流。因此，推测编辑的视频可能通过双重压缩文物的手段无法检测。在这方面，‘Adobe premiere’工具箱是我们的测试设置唯一的例外。商业软件是主要的专业视频编辑工具之一，但不支持无损伤处理。
我们已经写了自己的自定义文件解析器来读取和提取所有可用的视频文件格式信息和来自我们数据库中的元数据。因为它是不可能的详细描述所有的模型和本文讨论范围内供应商的特殊奇异之处，下面的章节重点在于选择结果和观察，我们认为这些对常见的视频容器格式的实用法医认证分析有很大的相关性。
一般观察
在我们的数据库中，大部分的数码相机存储视频以AVI容器格式。只有少数的测试设备使用Apple Quicktime MOV的容器格式。我们发现，大多数数码相机使用使用Motion JPEG压缩视频数据，其中的每个视频帧被处理作为独立的JPEG压缩图像。在我们的样本中只有三个型号的相机，使用更复杂的和有效的压缩算法。在压缩之前，框架一般都转换为YUV颜色空间。我们遇到4:2:2和4:2:0子采样降低色度通道的色度。MJPEG压缩视频流的分辨率，利用范围为256强度等级的全强度，8位编码帧（yuvj422p或yuvj420p），而DivX或者XviD支持的相机模型（yuv420p）只使用数量减少的220 / 225强度等级的亮度/色度通道（ITU-R推荐BT.601-7，2011）。视频容器中的音频数据通常存储作为原始数据（PCM），使用线性（8-16位）或对数（μ-law）量化。
在我们的数据库中所有的手机存储视频数据在以MOV基础容器格式（MOV，3GP，MP4）。LG的KU990拍照手机是一个例外，同时还支持AVI的容器。有趣的是，没有手机采用MJPEG压缩。相反，更复杂的压缩算法找到应用，例如， H.263，H.264，MPEG-4视频（简单配置文件）或DivX。二次抽样总是遵循4:2:0格式。与数码相机的视频相反，手机视频的音频轨道通常也受到有损压缩。我们发现基于MPEG的音频压缩或自适应多速率音频编解码器（AMR-NB）是最常见的。后者是用于语音编码最优化的标准（第三代合作伙伴项目，1999），这是很常见的，在手机中用于GSM和UMTS网络而设计。
AVI容器格式
在1992年，微软推出AVI（音频、视频转换）作为一个多媒体封装格式，它可以包含视频和音频流（微软开发者网络）。
一般的文件结构
AVI文件以一个强制性的AVI RIFF（资源交换文件格式）页眉开始。所有接下来的数据整理和存储在所谓的列表和块中。一个四字符的代码（Four CC）用来识别这些数据段。对于一个列表来说，Four CC就是LIST。不同的Four CC存在于块中，例如，JUNK或IDX1。没有严格的规范，即定义序列和列表和块的出现。
图1说明了基本文件结构，我们发现它同样出现在通过数码相机或手机拍摄的所有检查的AVI文件中。在AVI RIFF页眉之后，所有的设备直接存储强制列表hdrl。这个列表段压缩所有的信息，这些信息是必要的对于再压缩储存在文件中的视频和音频数据。在页眉和hdrl列表之后，第三大强制性AVI段是MOVI列表。它包含实际的视频和音频数据。根据特定的相机或手机型号，额外的列表和/或JUNK块的可能存在于hdrl和MOVI列表之间。这些可选择的数据段是用来填充或存储的元数据。idxl块索引数据块和它们在文件中的位置。正如提到的，在AVI文件引用中作为一个可选的元素（微软作为在AVI文件引用（微软开发者网络，0 0 0 0），但是在我们的数据库中所有视频文件中都能发现它。
图1 用我们的相机获取得AVI文件的内部结构
相机模型的细节
我们的视频数据库的检查显示设备模型和软件厂商之间的相当大的差异，选择哪一个，我们接下来做了讨论。这些和相关的特性，可以用来测试来验证或推断质疑视频内容的来源。
图2举例说明了录像记录的四种典型的AVI文件结构，这些记录来自佳能A640，佳能S45，尼康Coolpix S3300理光GX100数码相机。树状陈述反映AVI容器格式的嵌套字符和按其在各自的文件中的实际顺序，描述了所有主要的列表和块。相应的元素排列在同一水平面。数字表明并不是所有文件共享相同的组件，内容和特定的块的格式这两者可能有所不同。例如，尼康相机，不使用IDIT块存储记录日期，但增加了一个专用的ncdt列表整理元数据。在页眉流之后，所有四台相机插入一个不同内容的INFO列表。这两个佳能相机进一步的区别于IDIT日期规范的格式，但他们都没有使用相同的格式像理光GX100一样。
图2佳能545，尼康Pix533000，以及理光数码相机获取的视频AVI的结构
我们还发现，用MJPEG压缩的数码相机可以指定视频编解码器以小写或大写字母的形式。佳能Ixus IIs，佳能PowerShot（A640，S45，S70），尼康Coolpix，宾得W60，理光GX100，卡西欧EX-M2相机采用mjpg，而所有其他的测试相机宁愿选择字符串‘MJPG’。在hdrl表有进一步的变化。爱克发sensor505-x相机增加了一个额外的数据流描述，其中提到了供应商的名字。宾得Optio A40相机明确指定信息流的名字（视频或音频）。在hdrl列表中，来自LGKU990手机的视频和音频流紧跟着JUNK块。类似于图2中的例子，大多数型号的相机，在hdrl列表之后增加自己的INFO列表，用来提供额外的元数据。在这里，填充JUNK数据块是常见的。
视频编辑
在我们的测试设置中，所有的软件工具在编辑AVI视频文件结构中留下明显的痕迹，这不符合任何在我们的数据库中的相机特性。甚至无损坏的编辑视频也是这样检测的，通过与参考声称源的质疑文件的文件结构进行对比。
图3给出了两个具体的例子。在分别使用Avidemux和VirtualDub工具编辑之后，熟悉的树状图描绘了一个佳能A640视频AVI文件结构。原始文件结构的差异（在图2的最左边部分显示）用灰色背景打印。观察到这两种工具把JUNK块放在音频和视频流的描述结束之后的第hdrl列表上。VirtualDub增加了使用OpenDML AVI数据页眉的另一个列表。同样的工具扩展了自己的顶层文件层次，通过自己识别的JUNK块（‘VirtualDub建立32842/释放’）。 Avidemux以大写字母的形式改变了视频编解码器信息。其他的编辑软件留下自己的痕迹。例如，FFmpeg也可以插入其他的JUNK块。这些条目的内容是固定的和对于FFmpeg流速是具体的。此外，有关的就业编码器软件和版本细节的清单信息（这里是Lavf54.59.106）出现在使用FFmpeg编辑的视频中。
图3在分别使用Avidemux和VirtualDub工具编辑之后，熟悉的树状图描绘了一个佳能A640视频AVI文件结构。原始文件结构的差异（在图2的最左边部分显示）用灰色背景打印。
会暗示该记录设备的元数据列表和JUNK块通常在编辑文件中很容易丢失。虚拟配音是一个例外，并追加的原始文件的专门设备的INFO列表到编辑视频（参见图3）。然而，在一般情况下，无损坏的编辑视频流可能仍然包含源相机的不同压缩特性，我们将在这一节进行讨论（MJPEG压缩参数）。
QuickTime和相关的容器格式（MP4，3GP）
在1991年，MOV容器格式是由苹果公司为了它的QuickTime多媒体框架而引入的。后来它被用作MP4和3GP容器规格的基础（苹果电脑公司，2001；ISO/IEC14496，2003；第三代合作伙伴项目2004）。为了简单起见，我们提到的所有的三个容器格式是MP4格式。
一般的文件结构
类似于AVI格式，像MP4类的容器包括个人数据结构（“原子”或“盒子”） ，这是通过独特的四字节序列来确定的。关于原子大小的信息先于相应的标识符。原子可以被嵌套。虽然格式明确地不可以自行定义任何特定的顺序或数据段的数量，但是我们发现在图4中的一般结构存在于大多数被检查的文件中。像MP4类的视频文件通常先从ftyp原子开始，这是指该文件类型规格，其中文件是兼容的。实际的数据流存储在mdat原子中，该原子伴随着在moov原子对应的元数据。我们还遇到了使用moof原子的文件，其中包含基本流的短数据块。
相机型号的细节
更复杂的文件格式反映，像MP4类视频比AVI文件表现出更大程度的源依赖内部的变化。这是唯一的法医调查者的优势，他们会找这些有用的特征用于认证。然而，这已经超出了本文的范围，本文详细地讲述所有我们观察到的差异，而我们会关注于选择有代表性的例子。
在我们的数据库中，大多数的像MP4类的视频以ftyp原子开始，但我们也发现了一些例外。例如，柯达视频，以跳跃原子开始，而美能达Z1视频把pnot原子放置在文件的开头作为一个参考来预览数据。对Praktica DC2070相机根本不使用页眉，直接以mdat原子开始。由于像MP4类容器格式与大量的不同的数据格式，编解码器和参数化相兼容，如果目前的状态，ftyp原子的规格在各大品牌领域是“最佳使用”文件。额外的域就是列出次要版本和兼容的品牌。表2报道了我们的数据库中ftyp主要部分的组合和兼容品牌的规格。这表明，这表明这些规格可以不同，在很大的程度上，介于不同的记录设备。我们不报minor_version领域，就像我们平时发现它设置为0 。这些规格可以不同，不同的录音设备之间的一个大的程度。我们不报告minor_version领域，因为我们通常发现它设置为0。
表2 存储在MP4 ftyp报原子与各大品牌兼容
在像MP4类文件中，moov原子是最复杂的数据结构之一。它指定了解码参数用于正确解析mdatdata流。原子本身由多个子结构组成，如一般的mvhd电影头原子或更具体的mdhd媒体头原子。我们发现，参数设置在很大程度上取决于特定相机的型号。表3示例性地总结了对于time_scale领域的设置，该领域同时控制帧速率，音频采样率。观察mvhd和mdhd原子可以定义这个领域的不同价值，以及在不同的组合录制设备之间所相应的他们的组合的变化。
表3存储在MP4 MOOV原子time_scale fileld值，通过遍历每个设备的所有的可用的质量设置观察。符号‘.’表示mvhd和mdhd条目没有区别。
除了（准）标准的ftyp，mdat和moov原子，我们也遇到了各种各样的其它元素在像MP4类视频文件。表4表明了总的看法，例如，存储元数据在udta用户数据原子的一些原因，或使用自由原子填充。由于原子的特定的顺序一般是没有明确的定义，这里也存在着差异，最后并不奇怪。值得注意的偏差是明基S88和诺基亚X-300视频。前者遵循ftyp moov mdat 序列（而且是可选的多个moof mda后续对）。后者整理以ftyp moov自由和mdat自由。摩托罗拉里程碑展示了另一个有趣的特性。在这里，音频流领先于视频流。
表4在MP4类文件的其他原子
视频编辑
像AVI编辑这种情况，在我们的测试集通过编辑软件生成的像MP4类文件，在我们的数据库中没有一个与任何记录设备相兼容。在表2-4最底部三行举例说明了FFmpeg，YAMB，和Adobe Premiere CS5 的一些差异。我们可以观察到，每个软件都有自己独特的标志，它强调了在认证方案这些特性的实用性。
表2表明，主要的和兼容品牌组合和顺序应该特别有象征性。time_scale领域的检查发现，FFmpeg， Avidemux和FreeVideoDub总是设置mvhd值到1000，和一个mdhd（视频）值取决于原始帧速率。其他工具采用不同规格（参见表3）。表4显示，三星SGH -D600视频分享额外的iod对象使用编辑YAMB和Adobe Premiere视频描述原子的存在，而后两个还分别使用额外的tref和uuid原子。在我们的测试集中，基于ffmpeg的软件是唯一一个，该测试集把一个edts编辑列表增加到原子中。我们还观察到，AVIDemux设定编辑文件的采集时间和修改时间不正确到01-01-1904。
MJPEG压缩参数
支持的容器格式的独立性，在我们的数据库中，大多数的数码相机使用的Motion JPEG（MJPEG）来编码录制视频（参见表1）。单独的MJPEG帧存储为JPEG压缩的静止图像，图像它本身包含标记段。这样的片段通过2个字节的数字在本质上被确定，通常采用来自JPEG标准的已知的字符序列来缩写（见表格5）。基于我们对JPEG文件取证以前的工作，再这里我们希望特定段的存在和顺序也取决于记录装置。
表5 常见的JPEG文件标记。符号‘x’表示强制性标记（JIF的熵编码表不局限于DHT）
对于我们的测试集中所有的MJPEG视频，我们观察到一个视频的所有帧的JPEG标记段的相同顺序。在不同的相机型号之间差别确实存在。在这些群体中，JPEG标记片段的序列是独立于各个量化的设置。表6总结了我们对于MJPEG支撑和相应的缩略图的摄像机的发现（如果可用的话）。有趣的是， MJPEG帧不严格按照JFIF（汉密尔顿，1992）或JPEG / Exif图像（日本电子信息技术产业协会，2002）标准。大多数相机相反识别JPEG帧通过一个AVI应用程序数据段的方式（APP0（AVI1））。同时JPEG标记段的选择-在某些情况下，甚至他们的序列是不同于同一个数码相机的JPEG静态图像。
表6 在MJPEG视频压缩的JPEG标记段序列
例如，柯达M1063视频帧，包含AVI和JFIF应用数据段的组合，而Praktica DC2070数码相机使用一个特定的APP1（0x0000 MJPG）标记段。在哈夫曼编码和量化表的整合中也存在差异。旧的佳能相机型号（S45，S70，IXUS IIS）使用App2标记段而不是专用的DHT标记段来存储Huffman表用于熵编码。佳能A640，卡西欧EX-M2，理光GX-100视频帧，依赖于标准化的Huffman表而且随着帧不存储表。相反，柯达M1063和美能达Z1相机使用四个DHT标记片段，即每一个表对应一个段而不是一个单独的DHT标记片段对应于所有的四个表。同一型号的相机使用两个DQT段而不是一个，来存储两个必需的量化表。美能达视频的另一个特点是后续帧之间的填充位。
更有趣的注意到，我们在相对较小的一套测试影片中，我们确定了2914个引人注目的JPEG量化表的数目（仅使用亮度信息）。我们参照表7的概述。这种大量的数目可主要归因于根据相关的拍摄场景而自适应量化设置的相机。我们发现，这些摄像机也可能在同一视频帧之间切换量化表。支持在德累斯顿图像数据库（Gloe ，2012）有可适应量化表的缩略图图像类似的经验，我们对于MJPEG视频帧的观测极力强调，当法医调查者尝试创建可量化参数的综合数据库时，他们不得不应对这种挑战。
表7 MJPEG视频独特的量化表号
我们使用标记段结束了这一节，标记段的特征（和量化表）是最有用的用于验证或确定一个MJPEG视频的源设备（或一组设备）。无损伤视频编辑并没有修改MJPEG框架的内部结构。这是不同于JPEG文件的分析，在这里我们报道了在已处理图像的文件结构中软件特有的痕迹（Gloe，2012）。同时，然而，任何视频编辑软件可能会以它自己的特定的方式来改变容器格式的结构。因此，基于文件结构的信息来检测无损伤视频的编辑仍然是有可能的，参见我们对AVI视频格式的讨论（摄像机型号的细节）。
总结和结束语
本文从法医认证的角度提出了对流行的视频容器格式的第一个系统的解释。具体来说，我们把重点放在AVI和像MP4类（MOV ，3GP ，MP4）多媒体容器的内部文件结构。我们从19种数码相机，14种手机，和各种视频编辑工具表明大量的型号和具体的软件的特点。这种鉴别特征补充了取证人员的工具箱，同时提供有价值的线索来验证数字视频流的真实性。
我们的主要成果可概括如下：
数码相机和十部移动电话的视频使用不同的容器格式和压缩编解码器。手机选择先进的压缩算法(MP4V, H.26x)。在我们的测试集中，大多数数码相机宁愿选择AVI容器和基本的MJPEG压缩相结合。
AVI和像MP4之类的容器的结构没有严格地定义。在顺序和单独数据段的存在这两者之间，我们观察到相当大的差异。AVI文件通常包含特定的INFO列表或JUNK块。像MP4类的文件可以采用各种非标准的原子和特定原子条目的不同参数化。
不同型号的相机实现了对于MJPEG压缩的视频帧不同的JPEG标记段序列。内容自适应量化表似乎比JPEG图像更加频繁。MJPEG框架和JPEG静止图像标记序列和相同的相机型号的压缩设置可以完全不相交。
无损伤视频编辑让原始视频流原封不动的压缩设置遥不可及，但介绍了容器文件结构中其独特的工件。尽管真正的源设备的文件格式的特点在视频编辑之后通常丢失，但是在我们的测试集中所有的测试软件工具都具有独特的文件格式特性。
我们注意到，我们的测试集不包括每种相机型号的多台设备，所以我们只能推测，我们的观察同时归纳到同一型号的任意设备。然而，这是可以预料的，因为我们的观察有类似的报告，关于JPEG静止图像的结构，原始图像格式，和MP3音频文件。因为我们的分析依赖于文件结构的内部，我们目前并不知悉有任何可公开获得的软件，这能够让用户始终伪造这样的信息而没有先进的编程技巧。这使得建立合理伪造的，无疑是一个极不平凡的事业，从而再次强调该文件的特性和元数据不能被解雇，作为文件认证本身的目的不可靠来源的证据。
我们注意到，进一步的检查将展示多么独特的视频文件格式的特点是在更大的规模。这是毫无疑问的，不同的录音设备和编辑软件的识别一般差异也可以结合一个基于特征的定量的方法正如Kee等人（2011）对于JPEG文件提出的问题。从实际情况的观点出发，然而，我们相信，这样的“简明”的签名是从来没有最优的，因为他们不利用所有可用的信息。这尤其是当我们考虑到视频容器格式是远远（和不太严格的定义），比JPEG格式更为复杂。同时，它是一个开放的问题，关于更全面的签名将如何权衡所有未知文件格式的变化，这无疑仍然存在于野外，而且也关于现代流线型的智能手机设计都围绕着标准的开开放源代码或基于供应商的参考实现到什么程度。我们只能猜测特定源文件解析器的收集，它模仿一个法医调查者仔细的手工检查，有助于法医认证方案。未来的工作将要探讨此类解析器的规格如何能够实现自动化以及这种方法是如何的实用用于大型源识别程序。
毕业设计（论文）原创性声明和使用授权说明
原创性声明
本人郑重承诺：所呈交的毕业设计（论文），是我个人在指导教师的指导下进行的研究工作及取得的成果。尽我所知，除文中特别加以标注和致谢的地方外，不包含其他人或组织已经发表或公布过的研究成果，也不包含我为获得 及其它教育机构的学位或学历而使用过的材料。对本研究提供过帮助和做出过贡献的个人或集体，均已在文中作了明确的说明并表示了谢意。
作 者 签 名： 日 期：
指导教师签名： 日 期：
使用授权说明
本人完全了解 大学关于收集、保存、使用毕业设计（论文）的规定，即：按照学校要求提交毕业设计（论文）的印刷本和电子版本；学校有权保存毕业设计（论文）的印刷本和电子版，并提供目录检索与阅览服务；学校可以采用影印、缩印、数字化或其它复制手段保存论文；在不以赢利为目的前提下，学校可以公布论文的部分或全部内容。
作者签名： 日 期：
学位论文原创性声明
本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所取得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写的成果作品。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律后果由本人承担。
作者签名：
日期： 年 月 日
学位论文版权使用授权书
本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权 大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。
涉密论文按学校规定处理。
作者签名：
日期： 年 月 日
导师签名： 日期： 年 月 日
指导教师评阅书
指导教师评价：
一、撰写（设计）过程
1、学生在论文（设计）过程中的治学态度、工作精神
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、学生掌握专业知识、技能的扎实程度
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、学生综合运用所学知识和专业技能分析和解决问题的能力
□ 优 □ 良 □ 中 □ 及格 □ 不及格
4、研究方法的科学性；技术线路的可行性；设计方案的合理性
□ 优 □ 良 □ 中 □ 及格 □ 不及格
5、完成毕业论文（设计）期间的出勤情况
□ 优 □ 良 □ 中 □ 及格 □ 不及格
二、论文（设计）质量
1、论文（设计）的整体结构是否符合撰写规范？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、是否完成指定的论文（设计）任务（包括装订及附件）？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
三、论文（设计）水平
1、论文（设计）的理论意义或对解决实际问题的指导意义
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、论文的观念是否有新意？设计是否有创意？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、论文（设计说明书）所体现的整体水平
□ 优 □ 良 □ 中 □ 及格 □ 不及格
建议成绩：□ 优 □ 良 □ 中 □ 及格 □ 不及格
（在所选等级前的□内画“√”）
指导教师： （签名） 单位： （盖章）
年 月 日
评阅教师评阅书
评阅教师评价：
一、论文（设计）质量
1、论文（设计）的整体结构是否符合撰写规范？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、是否完成指定的论文（设计）任务（包括装订及附件）？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
二、论文（设计）水平
1、论文（设计）的理论意义或对解决实际问题的指导意义
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、论文的观念是否有新意？设计是否有创意？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、论文（设计说明书）所体现的整体水平
□ 优 □ 良 □ 中 □ 及格 □ 不及格
建议成绩：□ 优 □ 良 □ 中 □ 及格 □ 不及格
（在所选等级前的□内画“√”）
评阅教师： （签名） 单位： （盖章）
年 月 日
教研室（或答辩小组）及教学系意见
教研室（或答辩小组）评价：
一、答辩过程
1、毕业论文（设计）的基本要点和见解的叙述情况
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、对答辩问题的反应、理解、表达情况
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、学生答辩过程中的精神状态
□ 优 □ 良 □ 中 □ 及格 □ 不及格
二、论文（设计）质量
1、论文（设计）的整体结构是否符合撰写规范？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、是否完成指定的论文（设计）任务（包括装订及附件）？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
三、论文（设计）水平
1、论文（设计）的理论意义或对解决实际问题的指导意义
□ 优 □ 良 □ 中 □ 及格 □ 不及格
2、论文的观念是否有新意？设计是否有创意？
□ 优 □ 良 □ 中 □ 及格 □ 不及格
3、论文（设计说明书）所体现的整体水平
□ 优 □ 良 □ 中 □ 及格 □ 不及格
评定成绩：□ 优 □ 良 □ 中 □ 及格 □ 不及格
（在所选等级前的□内画“√”）
教研室主任（或答辩小组组长）： （签名）
年 月 日
教学系意见：
系主任： （签名）
年 月 日
学位论文原创性声明
本人郑重声明：所呈交的学位论文，是本人在导师的指导下进行的研究工作所取得的成果。尽我所知，除文中已经特别注明引用的内容和致谢的地方外，本论文不包含任何其他个人或集体已经发表或撰写过的研究成果。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式注明并表示感谢。本人完全意识到本声明的法律结果由本人承担。
学位论文作者（本人签名）： 年 月 日
学位论文出版授权书
本人及导师完全同意《中国博士学位论文全文数据库出版章程》、《中国优秀硕士学位论文全文数据库出版章程》(以下简称“章程”)，愿意将本人的学位论文提交“中国学术期刊（光盘版）电子杂志社”在《中国博士学位论文全文数据库》、《中国优秀硕士学位论文全文数据库》中全文发表和以电子、网络形式公开出版，并同意编入CNKI《中国知识资源总库》，在《中国博硕士学位论文评价数据库》中使用和在互联网上传播，同意按“章程”规定享受相关权益。
论文密级：
□公开
□保密（___年__月至__年__月）(保密的学位论文在解密后应遵守此协议)
作者签名：_______ 导师签名：_______
_______年_____月_____日 _______年_____月_____日
独 创 声 明
本人郑重声明：所呈交的毕业设计(论文)，是本人在指导老师的指导下，独立进行研究工作所取得的成果，成果不存在知识产权争议。尽我所知，除文中已经注明引用的内容外，本设计（论文）不含任何其他个人或集体已经发表或撰写过的作品成果。对本文的研究做出重要贡献的个人和集体均已在文中以明确方式标明。
本声明的法律后果由本人承担。
作者签名:
二〇一〇年九月二十日
毕业设计（论文）使用授权声明
本人完全了解滨州学院关于收集、保存、使用毕业设计（论文）的规定。
本人愿意按照学校要求提交学位论文的印刷本和电子版，同意学校保存学位论文的印刷本和电子版，或采用影印、数字化或其它复制手段保存设计（论文）；同意学校在不以营利为目的的前提下，建立目录检索与阅览服务系统，公布设计（论文）的部分或全部内容，允许他人依法合理使用。
（保密论文在解密后遵守此规定）
作者签名:
二〇一〇年九月二十日
致 谢
时间飞逝，大学的学习生活很快就要过去，在这四年的学习生活中，收获了很多，而这些成绩的取得是和一直关心帮助我的人分不开的。
首先非常感谢学校开设这个课题，为本人日后从事计算机方面的工作提供了经验，奠定了基础。本次毕业设计大概持续了半年，现在终于到结尾了。本次毕业设计是对我大学四年学习下来最好的检验。经过这次毕业设计，我的能力有了很大的提高，比如操作能力、分析问题的能力、合作精神、严谨的工作作风等方方面面都有很大的进步。这期间凝聚了很多人的心血，在此我表示由衷的感谢。没有他们的帮助，我将无法顺利完成这次设计。
首先，我要特别感谢我的知道郭谦功老师对我的悉心指导，在我的论文书写及设计过程中给了我大量的帮助和指导，为我理清了设计思路和操作方法，并对我所做的课题提出了有效的改进方案。郭谦功老师渊博的知识、严谨的作风和诲人不倦的态度给我留下了深刻的印象。从他身上，我学到了许多能受益终生的东西。再次对周巍老师表示衷心的感谢。
其次，我要感谢大学四年中所有的任课老师和辅导员在学习期间对我的严格要求，感谢他们对我学习上和生活上的帮助，使我了解了许多专业知识和为人的道理，能够在今后的生活道路上有继续奋斗的力量。
另外，我还要感谢大学四年和我一起走过的同学朋友对我的关心与支持，与他们一起学习、生活，让我在大学期间生活的很充实，给我留下了很多难忘的回忆。
最后，我要感谢我的父母对我的关系和理解，如果没有他们在我的学习生涯中的无私奉献和默默支持，我将无法顺利完成今天的学业。
四年的大学生活就快走入尾声，我们的校园生活就要划上句号，心中是无尽的难舍与眷恋。从这里走出，对我的人生来说，将是踏上一个新的征程，要把所学的知识应用到实际工作中去。
回首四年，取得了些许成绩，生活中有快乐也有艰辛。感谢老师四年来对我孜孜不倦的教诲，对我成长的关心和爱护。
学友情深，情同兄妹。四年的风风雨雨，我们一同走过，充满着关爱，给我留下了值得珍藏的最美好的记忆。
在我的十几年求学历程里，离不开父母的鼓励和支持，是他们辛勤的劳作，无私的付出，为我创造良好的学习条件，我才能顺利完成完成学业，感激他们一直以来对我的抚养与培育。
最后，我要特别感谢我的导师赵达睿老师、和研究生助教熊伟丽老师。是他们在我毕业的最后关头给了我们巨大的帮助与鼓励，给了我很多解决问题的思路，在此表示衷心的感激。老师们认真负责的工作态度，严谨的治学精神和深厚的理论水平都使我收益匪浅。他无论在理论上还是在实践中，都给与我很大的帮助，使我得到不少的提高这对于我以后的工作和学习都有一种巨大的帮助，感谢他耐心的辅导。在论文的撰写过程中老师们给予我很大的帮助，帮助解决了不少的难点，使得论文能够及时完成，这里一并表示真诚的感谢。
毕业设计（论文）原创性声明和使用授权说明
原创性声明
本人郑重承诺：所呈交的毕业设计（论文），是我个人在指导教师的指导下进行的研究工作及取得的成果。尽我所知，除文中特别加以标注和致谢的地方外，不包含其他人或组织已经发表或公布过的研究成果，也不包含我为获得 及其它教育机构的学位或学历而使用过的材料。对本研究提供过帮助和做出过贡献的个人或集体，均已在文中作了明确的说明并表示了谢意。
作 者 签 名： 日 期：
指导教师签名： 日 期：
使用授权说明
本人完全了解 大学关于收集、保存、使用毕业设计（论文）的规定，即：按照学校要求提交毕业设计（论文）的印刷本和电子版本；学校有权保存毕业设计（论文）的印刷本和电子版，并提供目录检索与阅览服务；学校可以采用影印、缩印、数字化或其它复制手段保存论文；在不以赢利为目的前提下，学校可以公布论文的部分或全部内容。
作者签名： 日 期：
学位论文原创性声明
本人郑重声明：所呈交的论文是本人在导师的指导下独立进行研究所取得的研究成果。除了文中特别加以标注引用的内容外，本论文不包含任何其他个人或集体已经发表或撰写的成果作品。对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完全意识到本声明的法律后果由本人承担。
作者签名：
日期： 年 月 日
学位论文版权使用授权书
本学位论文作者完全了解学校有关保留、使用学位论文的规定，同意学校保留并向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅和借阅。本人授权 大学可以将本学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存和汇编本学位论文。
涉密论文按学校规定处理。
作者签名：
日期： 年 月 日
导师签名： 日期： 年 月 日
独 创 声 明
本人郑重声明：所呈交的毕业设计(论文)，是本人在指导老师的指导下，独立进行研究工作所取得的成果，成果不存在知识产权争议。尽我所知，除文中已经注明引用的内容外，本设计（论文）不含任何其他个人或集体已经发表或撰写过的作品成果。对本文的研究做出重要贡献的个人和集体均已在文中以明确方式标明。
本声明的法律后果由本人承担。
作者签名:
年 月 日
毕业设计（论文）使用授权声明
本人完全了解**学院关于收集、保存、使用毕业设计（论文）的规定。
本人愿意按照学校要求提交学位论文的印刷本和电子版，同意学校保存学位论文的印刷本和电子版，或采用影印、数字化或其它复制手段保存设计（论文）；同意学校在不以营利为目的的前提下，建立目录检索与阅览服务系统，公布设计（论文）的部分或全部内容，允许他人依法合理使用。
（保密论文在解密后遵守此规定）
作者签名:
年 月 日
基本要求：写毕业论文主要目的是培养学生综合运用所学知识和技能，理论联系实际，独立分析，解决实际问题的能力，使学生得到从事本专业工作和进行相关的基本训练。毕业论文应反映出作者能够准确地掌握所学的专业基础知识，基本学会综合运用所学知识进行科学研究的方法，对所研究的题目有一定的心得体会，论文题目的范围不宜过宽，一般选择本学科某一重要问题的一个侧面。
毕业论文的基本教学要求是：
1、培养学生综合运用、巩固与扩展所学的基础理论和专业知识，培养学生独立分析、解决实际问题能力、培养学生处理数据和信息的能力。2、培养学生正确的理论联系实际的工作作风，严肃认真的科学态度。3、培养学生进行社会调查研究；文献资料收集、阅读和整理、使用；提出论点、综合论证、总结写作等基本技能。
毕业论文是毕业生总结性的独立作业，是学生运用在校学习的基本知识和基础理论，去分析、解决一两个实际问题的实践锻炼过程，也是学生在校学习期间学习成果的综合性总结，是整个教学活动中不可缺少的重要环节。撰写毕业论文对于培养学生初步的科学研究能力，提高其综合运用所学知识分析问题、解决问题能力有着重要意义。
毕业论文在进行编写的过程中，需要经过开题报告、论文编写、论文上交评定、论文答辩以及论文评分五个过程，其中开题报告是论文进行的最重要的一个过程，也是论文能否进行的一个重要指标。
撰写意义：1.撰写毕业论文是检验学生在校学习成果的重要措施，也是提高教学质量的重要环节。大学生在毕业前都必须完成毕业论文的撰写任务。申请学位必须提交相应的学位论文，经答辩通过后，方可取得学位。可以这么说，毕业论文是结束大学学习生活走向社会的一个中介和桥梁。毕业论文是大学生才华的第一次显露，是向祖国和人民所交的一份有份量的答卷，是投身社会主义现代化建设事业的报到书。一篇毕业论文虽然不能全面地反映出一个人的才华，也不一定能对社会直接带来巨大的效益，对专业产生开拓性的影响。但是，实践证明，撰写毕业论文是提高教学质量的重要环节，是保证出好人才的重要措施。
2.通过撰写毕业论文，提高写作水平是干部队伍“四化”建设的需要。党中央要求，为了适应现代化建设的需要，领导班子成员应当逐步实现“革命化、年轻化、知识化、专业化”。这个“四化”的要求，也包含了对干部写作能力和写作水平的要求。
3.提高大学生的写作水平是社会主义物质文明和精神文明建设的需要。在新的历史时期，无论是提高全族的科学文化水平，掌握现代科技知识和科学管理方法，还是培养社会主义新人，都要求我们的干部具有较高的写作能力。在经济建设中，作为领导人员和机关的办事人员，要写指示、通知、总结、调查报告等应用文；要写说明书、广告、解说词等说明文；还要写科学论文、经济评论等议论文。在当今信息社会中，信息对于加快经济发展速度，取得良好的经济效益发挥着愈来愈大的作用。写作是以语言文字为信号，是传达信息的方式。信息的来源、信息的收集、信息的储存、整理、传播等等都离不开写作。
论文种类：毕业论文是学术论文的一种形式，为了进一步探讨和掌握毕业论文的写作规律和特点，需要对毕业论文进行分类。由于毕业论文本身的内容和性质不同，研究领域、对象、方法、表现方式不同，因此，毕业论文就有不同的分类方法。
按内容性质和研究方法的不同可以把毕业论文分为理论性论文、实验性论文、描述性论文和设计性论文。后三种论文主要是理工科大学生可以选择的论文形式，这里不作介绍。文科大学生一般写的是理论性论文。理论性论文具体又可分成两种：一种是以纯粹的抽象理论为研究对象，研究方法是严密的理论推导和数学运算，有的也涉及实验与观测，用以验证论点的正确性。另一种是以对客观事物和现象的调查、考察所得观测资料以及有关文献资料数据为研究对象，研究方法是对有关资料进行分析、综合、概括、抽象，通过归纳、演绎、类比，提出某种新的理论和新的见解。
按议论的性质不同可以把毕业论文分为立论文和驳论文。立论性的毕业论文是指从正面阐述论证自己的观点和主张。一篇论文侧重于以立论为主，就属于立论性论文。立论文要求论点鲜明，论据充分，论证严密，以理和事实服人。驳论性毕业论文是指通过反驳别人的论点来树立自己的论点和主张。如果毕业论文侧重于以驳论为主，批驳某些错误的观点、见解、理论，就属于驳论性毕业论文。驳论文除按立论文对论点、论据、论证的要求以外，还要求针锋相对，据理力争。
按研究问题的大小不同可以把毕业论文分为宏观论文和微观论文。凡届国家全局性、带有普遍性并对局部工作有一定指导意义的论文，称为宏观论文。它研究的面比较宽广，具有较大范围的影响。反之，研究局部性、具体问题的论文，是微观论文。它对具体工作有指导意义，影响的面窄一些。
另外还有一种综合型的分类方法，即把毕业论文分为专题型、论辩型、综述型和综合型四大类：
1．专题型论文。这是分析前人研究成果的基础上，以直接论述的形式发表见解，从正面提出某学科中某一学术问题的一种论文。如本书第十二章例文中的《浅析领导者突出工作重点的方法与艺术》一文，从正面论述了突出重点的工作方法的意义、方法和原则，它表明了作者对突出工作重点方法的肯定和理解。2．论辩型论文。这是针对他人在某学科中某一学术问题的见解，凭借充分的论据，着重揭露其不足或错误之处，通过论辩形式来发表见解的一种论文。3．综述型论文。这是在归纳、总结前人或今人对某学科中某一学术问题已有研究成果的基础上，加以介绍或评论，从而发表自己见解的一种论文。4．综合型论文。这是一种将综述型和论辩型两种形式有机结合起来写成的一种论文。如《关于中国民族关系史上的几个问题》一文既介绍了研究民族关系史的现状，又提出了几个值得研究的问题。因此，它是一篇综合型的论文。
写作步骤：毕业论文是高等教育自学考试本科专业应考者完成本科阶段学业的最后一个环节，它是应考者的 总结 性独立作业，目的在于总结学习专业的成果，培养综合运用所学知识解决实际 问题 的能力。从文体而言，它也是对某一专业领域的现实问题或 理论 问题进行 科学 研究 探索的具有一定意义的论说文。完成毕业论文的撰写可以分两个步骤，即选择课题和研究课题。
首先是选择课题。选题是论文撰写成败的关键。因为，选题是毕业论文撰写的第一步，它实际上就是确定“写什么”的问题，亦即确定科学研究的方向。如果“写什么”不明确，“怎么写”就无从谈起。
教育部自学考试办公室有关对毕业论文选题的途径和要求是“为鼓励理论与工作实践结合，应考者可结合本单位或本人从事的工作提出论文题目，报主考学校审查同意后确立。也可由主考学校公布论文题目，由应考者选择。毕业论文的总体要求应与普通全日制高等学校相一致，做到通过论文写作和答辩考核，检验应考者综合运用专业知识的能力”。但不管考生是自己任意选择课题，还是在主考院校公布的指定课题中选择课题，都要坚持选择有科学价值和现实意义的、切实可行的课题。选好课题是毕业论文成功的一半。
第一、要坚持选择有科学价值和现实意义的课题。科学研究的目的是为了更好地认识世界、改造世界，以推动社会的不断进步和发展 。因此，毕业论文的选题，必须紧密结合社会主义物质文明和精神文明建设的需要，以促进科学事业发展和解决现实存在问题作为出发点和落脚点。选题要符合科学研究的正确方向，要具有新颖性，有创新、有理论价值和现实的指导意义或推动作用，一项毫无意义的研究，即使花很大的精力，表达再完善，也将没有丝毫价值。具体地说，考生可从以下三个方面来选题。首先，要从现实的弊端中选题，学习了专业知识，不能仅停留在书本上和理论上，还要下一番功夫，理论联系实际，用已掌握的专业知识，去寻找和解决工作实践中急待解决的问题。其次，要从寻找科学研究的空白处和边缘领域中选题，科学研究。还有许多没有被开垦的处女地，还有许多缺陷和空白，这些都需要填补。应考者应有独特的眼光和超前的意识去思索，去发现，去研究。最后，要从寻找前人研究的不足处和错误处选题，在前人已提出来的研究课题中，许多虽已有初步的研究成果，但随着社会的不断发展，还有待于丰富、完整和发展，这种补充性或纠正性的研究课题，也是有科学价值和现实指导意义的。
第二、要根据自己的能力选择切实可行的课题。毕业论文的写作是一种创造性劳动，不但要有考生个人的见解和主张，同时还需要具备一定的客观条件。由于考生个人的主观、客观条件都是各不相同的，因此在选题时，还应结合自己的特长、兴趣及所具备的客观条件来选题。具体地说，考生可从以下三个方面来综合考虑。首先，要有充足的资料来源。“巧妇难为无米之炊”，在缺少资料的情况下，是很难写出高质量的论文的。选择一个具有丰富资料来源的课题，对课题深入研究与开展很有帮助。其次，要有浓厚的研究兴趣，选择自己感兴趣的课题，可以激发自己研究的热情，调动自己的主动性和积极性，能够以专心、细心、恒心和耐心的积极心态去完成。最后，要能结合发挥自己的业务专长，每个考生无论能力水平高低，工作岗位如何，都有自己的业务专长，选择那些能结合自己工作、发挥自己业务专长的课题，对顺利完成课题的研究大有益处。
致 谢
这次论文的完成，不止是我自己的努力，同时也有老师的指导，同学的帮助，以及那些无私奉献的前辈，正所谓你知道的越多的时候你才发现你知道的越少，通过这次论文，我想我成长了很多，不只是磨练了我的知识厚度，也使我更加确定了我今后的目标：为今后的计算机事业奋斗。在此我要感谢我的指导老师——***老师，感谢您的指导，才让我有了今天这篇论文，您不仅是我的论文导师，也是我人生的导师，谢谢您！我还要感谢我的同学，四年的相处，虽然我未必记得住每分每秒，但是我记得每一个有你们的精彩瞬间，我相信通过大学的历练，我们都已经长大，变成一个有担当，有能力的新时代青年，感谢你们的陪伴，感谢有你们，这篇论文也有你们的功劳，我想毕业不是我们的相处的结束，它是我们更好相处的开头，祝福你们！我也要感谢父母，这是他们给我的，所有的一切；感谢母校，尽管您不以我为荣，但我一直会以我是一名农大人为荣。
通过这次毕业设计，我学习了很多新知识，也对很多以前的东西有了更深的记忆与理解。漫漫求学路，过程很快乐。我要感谢信息与管理科学学院的老师，我从他们那里学到了许多珍贵的知识和做人处事的道理，以及科学严谨的学术态度，令我受益良多。同时还要感谢学院给了我一个可以认真学习，天天向上的学习环境和机会。
即将结束*大学习生活，我感谢****大学提供了一次在**大接受教育的机会，感谢院校老师的无私教导。感谢各位老师审阅我的论文。
图3.1 系统用例图
图4.1 系统层次图
图4.2 主页面运行结果
图4.3 演唱者分类
图4.4 以专辑分类
图4.5 播放列表
图4.6 播放控制
图4.7 播放进度条
图4.8 打开按钮
图4.9 系统功能模块层次图
图5.1 艺术家树形结构
图5.2 open按钮
图5.3 打开文件对话框
图5.4 播放速率
图5.5 播放进度条
图4 用我们的相机获得最MP4样文件的内容结构
浙公网安备 33021202002483