以下是测试对问题的描述:
 
 有录音文件，卸载SD卡后，手机内存中的录音文件不显示
 
 【预置条件】保存有手机存储中的录音文件
 
 【操作步骤】菜单--设置--存储--卸载SD卡--录音列表--观察
 
 【实际结果】保存在手机内存的录音文件不显示
 
 【预期结果】保存在手机内存中的录音文件应正常显示
 
 【复现概率】必现
 
 
 
 
 问题分析:
 
 从问题的现象来看，是因为卸载了SD卡，导致原本能查找到的数据库内容变得不能被查到了，首先看录音文件列表的类RecordingFileList，其中cursor的创建如下：
 
 StringBuilder stringBuilder = new StringBuilder();
 
         stringBuilder.append(MediaStore.Audio.Media.IS_RECORD);
 
         stringBuilder.append(" =1");
 
         String selection = stringBuilder.toString();
 
         Cursor recordingFileCursor = getContentResolver().query(
 
                 MediaStore.Audio.Media.EXTERNAL_CONTENT_URI,
 
                 new String[] {
 
                         MediaStore.Audio.Media.ARTIST, MediaStore.Audio.Media.ALBUM,
 
                         MediaStore.Audio.Media.DATA, MediaStore.Audio.Media.DURATION,
 
                         MediaStore.Audio.Media.DISPLAY_NAME, MediaStore.Audio.Media.DATE_ADDED,
 
                         MediaStore.Audio.Media.TITLE, MediaStore.Audio.Media._ID
 
                 },selection, null, MediaStore.Audio.Media.DATE_ADDED + " DESC");//zhouwuping add "MediaStore.Audio.Media.DATE_ADDED + " DESC" to fix recordingfile sort by order for ACURAT-467.
 
 从查询条件看，并没有与sd卡卸载相关的内容。于是怀疑是否有相关查询条件会在卸载sd卡后改变。
 
 将复现问题的手机，导出数据库，可以查看到录音相关的数据库内容如下：
 
 在external数据库中，两个录音文件对应的is_record字段是0
 
 
 
 
 
 
 在external-5f7f0b31数据库中，两个录音文件对应的is_record字段是1
 
 
 
 可注意到数据库中路径的不同，说明在卸载sd卡后，录音文件的地址是没有问题的，于是尝试修改stringBuilder，去除is_record的判断条件，问题消失。（但此时其他类型的音频文件也会显示出来了）
 
 那么怀疑的对象就是为何is_record的值会变成0（并且此时，原本为0的is_music属性变成1了）
 
 Is_record字段是mtk为了避免录音机中显示非录音文件而加入的字段，否则在recording目录下拷贝进去的音频文件也会显示在列表中。
 
 录音完成后，将录音插到db中是没有问题的，代码如下：
 
 cv.put(MediaStore.Audio.Media.IS_RECORD,"1");
 
 那么问题肯定是发生在生成内置存储数据库的过程中了，猜测是由于某种疏漏，is_record字段没有被复制。而且is_record字段是项目中期mtk的代码升级添加的。
 
 重新抓一个插着sd卡，设置默认存储是内部存储的录音log，可以看到在录音完成，已经插入到db中后，系统启动了mediascan，扫描对象即是刚生成的录音文件。
 
 从log中可以找到，媒体扫描和database操作是在MediaScanner中完成的，对应的方法是doScanFile
 
 可以看到在媒体扫描中有写入is_music的动作，相关代码如下：
 
 判断是否是music：
 
 boolean music = (lowpath.indexOf(MUSIC_DIR) > 0) ||
 
 (!ringtones && !notifications && !alarms && !podcasts);
 
 处理音频类型的文件：
 
 if (isaudio || isvideo) {
 
     processFile(path, mimeType, this);
 
 }
 
 因此这里首先要对music的赋值进行修改，需要判断文件的目录是否是在Recording下，增加一个属性：
 
 boolean recordings = (lowpath.indexOf(RECORDING_DIR) > 0);//用于判断文件路径是否是在录音文件夹下
 
 其中RECORDING_DIR是录音的文件名：
 
 private static final String RECORDING_DIR = "/recording/";
 
 这样就可以判断新增的文件是否是放在录音目录下了，这样is_music就不会变成1了，但这样会有别的问题，如果拷贝音频文件到Recording目录，这些文件的is_music也会被置为0。
 
 如果去查询录音所在的数据库来判断，较为复杂，因此这儿先使用后缀名来进行判断，AL889的录音格式仅有3gpp和amr，做以下判断：
 
 boolean recordings = (lowpath.indexOf(RECORDING_DIR) > 0 && ( mFileType == MediaFile.FILE_TYPE_3GPP3 || mFileType == MediaFile.FILE_TYPE_AMR));
 
 数据库写入的最终执行，是在
 
         private Uri endFile(FileEntry entry, boolean ringtones, boolean notifications,
 
                 boolean alarms, boolean music, boolean podcasts)
 
 中进行的，原生的endFile方法并没有recording的判断，因此需要改造下方法，加入recording参数，当然对于原来没有recording传参的调用，做以下处理：
 
         private Uri endFile(FileEntry entry, boolean ringtones, boolean notifications,
 
                 boolean alarms, boolean music, boolean podcasts)
 
                 throws RemoteException {
 
             return endFile (entry, ringtones, notifications, alarms, music, podcasts, false);
 
         }
 
 这样在nomedia的条件下，也可以正确调用endFile方法了（仅在mediascanner内部被调用）
 
 并且新的endFile方法如下：
 
         private Uri endFile(FileEntry entry, boolean ringtones, boolean notifications,
 
                 boolean alarms, boolean music, boolean podcasts, boolean recordings)
 
                 throws RemoteException {
 
 ……
 
                 values.put(Audio.Media.IS_PODCAST, podcasts);
 
                 values.put(Audio.Media.IS_RECORD, recordings);//添加这一行，即写入is_record字段
 
             /// M: MAV type MPO file need parse some info from exif
 
             } else if ((mFileType == MediaFile.FILE_TYPE_JPEG || mFileType == MediaFile.FILE_TYPE_MPO) && !mNoMedia) {
 
 …
 
  
 
 修改以上之后，再执行相同的步骤，录音文件能够显示正确，查看database文件，此时在external表中的is_record字段值为1，验证此方案是有效的。
 
  
 
 PS：
 
 录音文件的MediaScan是如何发起的？
 
  
 
 录音完成后，通常的，在SoundRecorderService中的private Uri addToMediaDB(File file) 方法，负责将录音文件插入到数据库中。在方法的最后，执行了如下语句：
 
 MediaScannerConnection.scanFile(getApplicationContext(), new String[] {file.getAbsolutePath()}, null, null);
 
 因此在log中可以看到MediaScannerConnection首先启动了
 
 01-03 05:28:27.956 V/MediaScannerConnection( 2661): Connected to Media Scanner
 
 
 
 01-03 05:28:27.956 V/MediaScannerConnection( 2661): Scanning file /storage/sdcard1/Recording/record20140103052821.amr
 
 （另一种发起单个文件扫描的方式是使用intent：ACTION_MEDIA_SCANNER_SCAN_FILE，当该intent被接收，就会发起扫描）
 
  
 
 然后就是MediaScanner的部分了，调用scanFile方法后，MediaScannerConnection就会去binder对应的Service，就是MediaScannerService，具体可以看MediaScannerConnection中的onConnect方法
 
 开始执行MediaScannerService中的查找文件方法：
 
 首先在requestScanFile方法中，获取MediaScannerConnection处传入的参数，接着发了一个MSG_SCAN_SINGLE_FILE，于是通过handleScanSingleFile发起了单个文件的扫描。
 
  
 
 在扫描时，会发现文件的卷被定义成了MediaProvider.EXTERNAL_VOLUME，也就是external卷，而目前兼容T卡的机子，通常会有external和external+ID两个卷。那么媒体扫描是如何区分的呢，通过MediaProvider的
 
 private Uri attachVolume(String volume)
 
 其中有判断条件如下：
 
                 String primaryPath = Environment.getExternalStorageDirectory().getPath();
 
                 String externalPath = StorageManagerEx.getExternalStoragePath();
 
                 boolean isExternalStorageRemovable = (primaryPath != null && primaryPath.equals(externalPath));
 
  
 
 假如当前的外部存储是可卸载的（就是指T卡么），那么通过以下方法可以获取对应database的名字：
 
 String dbName = "external-" + Integer.toHexString(volumeId) + ".db";
 
 如果外部存储是不可卸载的话（没插T卡），那么数据库就会直接使用external.db,（里面还有个机制，如果没有external.db的话，会把external+id.db改名字，当然这种情况一般不发生）
 
 经过上面的判断，databasehelper就创建好了，有t卡的话就是external+id.db，没有的话就是external.db。
 
  
 
 而如上出现的卸载T卡事件，会被mediaProvider的mUnmountReceiver捕获，从而触发detachVolume（如果加载了T卡，则会执行attachVolume）
 
 detachVolume这个方法，作用就是分离不生效的卷，可看到执行这个方法后，external+id.db这个database就被分离了，此时生效的是external.db。
 
 01-02 04:02:11.448990  1270  3045 V MediaProvider: attachVolume>>> volume=external
 
 01-02 04:02:11.449030  1270  3045 V MediaProvider: attachVolume<<< Already attached external.db
 
 因此，在没有加载T卡的时候，使用的是external.db
 
 至于external.db中的数据是如何写入的，在卸载/加载T卡的时候，mediascanner会自动完成这一过程

 
 
 
 
 
 
 
AAC文件
 
 
资料：
 
 
http://blog.csdn.net/u013427969/article/details/53091594
 
 
http://blog.chinaunix.net/uid-26084833-id-3416600.html
 
 
http://blog.csdn.net/sunnylgz/article/details/7676340
 
 
 
 
 
AAC的音频文件格式有ADIF ＆ ADTS：
 
 
ADIF：Audio Data Interchange Format 音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。故这种格式常用在磁盘文件中。
 
 
  ADTS：Audio Data Transport Stream 音频数据传输流。这种格式的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。它的特征类似于mp3数据流格式。
 
 
AAC的ADTS头文件信息介绍：
 
 
http://blog.csdn.net/jay100500/article/details/52955232
 
 
http://blog.csdn.net/liukun321/article/details/25337425
 
 
http://blog.csdn.net/andyhuabing/article/details/40983423
 
 
.一加手机的录音文件是AAC格式的。
 
 
 
 
经过观察，这个音频文件格式为ADTS。对这种类型文件分析，可以参考下mp3文件的音频数据帧
 
 
---------------------------------------------------------------------------------------------------------------------------------------------
 
 
MP4文件格式
 
 
http://www.360doc.com/content/16/0304/16/6887512_539388342.shtml
 
 
http://blog.sina.com.cn/s/blog_48f93b530100jz4b.html
 
 
M4A文件头：
 
 
MP4文件中的所有数据都装在box（QuickTime中为atom）中，也就是说MP4文件由若干个box组成，每个box有类型和长度，可以将box理解为一个数据对象块。box中可以包含另一个box，这种box称为container box。一个MP4文件首先会有且只有一个“ftyp”类型的box，作为MP4格式的标志并包含关于文件的一些信息。
 
 
Box说明：
 
 
首先需要说明的是，box中的字节序为网络字节序，也就是大端字节序（Big-Endian），简单的说，就是一个32位的4字节整数存储方式为高位字节在内存的低端。
 
 
Box由header和body组成，
 
 
其中header统一指明box的大小和类型，
 
 
body根据类型有不同的意义和格式。
 
 
标准的box开头的4个字节（32位）为box size，该大小包括box header和box body整个box的大小，这样我们就可以在文件中定位各个box。
 
 
如果size为1，则表示这个box的大小为large size，真正的size值要在largesize域上得到。（实际上只有“mdat”类型的box才有可能用到large size。）如果size为0，表示该box为文件的最后一个box，文件结尾即为该box结尾。（同样只存在于“mdat”类型的box中。）
 
 
 
 
 
 
 
size后面紧跟的32位为box type，一般是4个字符，如“ftyp”、“moov”等，这些box type都是已经预定义好的，分别表示固定的意义。如果是“uuid”，表示该box为用户扩展类型。如果box type是未定义的，应该将其忽略。
 
 
box类型，增加一个wide类型。
 
 
 
 
 
 
 
 
后记mp4，AAC，M4A文件格式解析
 
 
m4a(aac编码)就是mp4格式的音频内容
 
 
m4a同mp3一样，也是一种音频格式的文件，但一般普通的m4a文件扩展名通常是mp4，由于苹果的iTunes的原因，现在大多数的音乐软件都直接支持了m4a。
 
 
如果遇到有m4a音频格式的文件，可以安全地把只包含音频的.mp4 文件的扩展名改成.m4a，以便让它能在你喜欢的播放器里播放，反过来转换也可以。
 
 
随着苹果手机iPhone和平板iPad的流行，使得iPhone和iPad中支持的m4a格式文件如今流行了起来。M4A是MPEG-4音频标准的文件的扩展名。
 
 
在MPEG4标准中提到，普通的MPEG4文件扩展名是“.mp4”。自从Apple开始在它的iTunes以及iPod中使用“.m4a”以区别MPEG4的视频和音频文件以来，
 
 
“.m4a”这个扩展名开始被大家认识。
 
 
 
 
 
注：AAC文件就是不经封装的音频流。M4A文件就是以MPEG-4标准的封装格式进行封装的AAC
 
 
 ====================================
 
 
文件的创建、修改时间的解析，思路:
 
 
计算得到：
 
 
1904-01-01零点 到 1970-01-01零点经过的秒数
 
 
把从文件中解析得到的秒数 减去 上面的秒数
 
 
得到的值就可以使用ctime函数了。
 
转载于:https://www.cnblogs.com/zhangxuan/p/8581223.html

核心方法：修改注册表(XP下通过） 1．在“开始”菜单的“运行”窗口中输入“regedit”命令后点击“确定”按钮。 2．在弹出的“注册表编辑器”窗口中找到下面的键：HKEY_CURRENT_USER→Software→Microsoft→Windows→CurrentVersion→Applets→Sound Recorder（如果没有Sound Recorder键，就自己建一个）,在Sound Recorder键的右边窗格中点击新建一个“字符串值”。 3、点击鼠标右键:将上述“字符串值”重命名为“BufferDeltaSeconds”,并修改键值，它可以是从 ASCⅡ字符“！”（为33秒）到“~“（为126秒）的任意一个字符（修改为“■”录音时间为350秒，可以满足约6分钟的录音时间要求）。

1.录音文件
 
前台测试代码：
 
 <form id="upload" enctype="multipart/form-data" method="post">
            <input type="file" name="file" id="pic"/>
            <input type="button" value="提交" onclick="uploadPic();"/>
            <span class="showUrl"></span>
            <img src="" class="showPic" alt="">
        </form>
 
function uploadPic() {
            var form = document.getElementById('upload'),
                    formData = new FormData(form);
            $.ajax({
                url:"http://localhost:8080/api/uploadVoiceFile",
                type:"post",
                data:formData,
                processData:false,
                contentType:false,
                success:function(res){
                    if(res){
                        alert(res+"上传成功！");
                    }
                    console.log(res);
                    $("#pic").val("");
                    $(".showUrl").html(res);
                    $(".showPic").attr("src",res);
                },
                error:function(err){
                    alert("网络连接失败,稍后重试",err);
                }
            })
        }
 
后台接收文件代码：
 
发现问题1：
 
SpringBoot下测试时，发现的该问题，即在解析请求时List list = upload.parseRequest(request);得到的list size=0,也就是根本没有得到文件数据。我在网上搜索该问题的解决方法，大致有以下两种：
 （1）原因在于Spring的配置文件中已经配置了MultipartResolver，导致文件上传请求已经被预处理过了，所以此处解析文件列表为空，对应的做法是删除该段配置。
 （2）认为是structs的过滤器导致请求已被预处理，所以也要修改对应过滤器的配置。
 然而，在SpringBoot下，上述两种解决方法不可能做到，因为SpringBoot的相关配置都是自己完成的，根本没有显示的配置文件。况且以上两种解决方法，修改配置文件可能影响整个工程的其他部分，所以得另寻方案。
 我通过断点调试该Controller代码，发现传入的参数HttpServletRequest实例已经为StandardMultipartHttpServletRequest 对象了，且其结构中包含整个form表单的所有字段信息，我就想，区别于网上已有的两种解决方案，总是想避免这种预处理，何不就利用这种预处理，来简化自己的代码结构呢？于是就有了下面的解决代码。其方法很简单，就是对传入的request做强制转型，从而可以根据StandardMultipartHttpServletRequest 实例方法得到相关form表单数据 。
 
	/**
	 * 上传文件（从request中获取inputstream）
	 * @param request
	 * @param response
	 * @return
	 * @throws ServletException
	 * @throws IOException
	 */
	@ResponseBody
	@PostMapping("/uploadVoiceFile")
	public void uploadVoiceFile(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		logger.info("进入上传文件uploadVoiceFile方法");
		try{
			boolean isMultipart = ServletFileUpload.isMultipartContent(request);
			String realpath =request.getContextPath()+"/audio/";
			String fileName = ""+System.currentTimeMillis();
			if (isMultipart) {
				File dir = new File(realpath);
				if (!dir.exists()){
					dir.mkdirs();
				}
				StandardMultipartHttpServletRequest req = (StandardMultipartHttpServletRequest) request;
				Iterator<String> iterator = req.getFileNames();
				while (iterator.hasNext()) {
					MultipartFile file = req.getFile(iterator.next());
					InputStream sis = file.getInputStream();
					//存储文件
					logger.info("创建音频文件"+request.getContextPath()+fileName+".amr");
					FileOutputStream fos = new FileOutputStream(request.getContextPath()+"/audio/"+fileName+".amr");
					logger.info("开始写音频文件");
					fos.write(file.getBytes()); // 开始写音频文件
					fos.flush();
					fos.close();
					String sourceDir = request.getContextPath()+"/audio/"+fileName+".amr";
					String targetDir = request.getContextPath()+"/audio/"+fileName+".mp3";
					changeToMp3(sourceDir, targetDir);
					response.getWriter().append(fileName);
					logger.info("文件地址"+request.getContextPath()+"/audio/"+fileName+".amr");
				}
			}else{
				response.getWriter().append("file not find error");
			}
		}catch (Exception e) {
			e.printStackTrace();
			logger.info(e.getMessage());
			logger.info(e.getStackTrace().toString());
		}
		logger.info("退出上传文件uploadVoiceFile方法");
	} 
 
 发现问题2：
 
项目需要将 amr 格式的文件转成 mp3格式，网络上提供的思路大多是使用jave-x-x.jar。
 这个包确实有用，因为开发时是在windows环境中，测试转换虽然报了异常：
 
it.sauronsoftware.jave.EncoderException:   Duration: N/A, bitrate: N/A
 
但也确实转换成功了，可以播放。
 可是一旦部署到Linux环境当中，不是转换失败，就是转换的文件为大小 0 k。
 
 
 
public static void changeToMp3(String sourceDir,String targetDir) throws InputFormatException {
		File source = new File(sourceDir);   // 源文件
		File target = new File(targetDir);   // 目标文件
		AudioAttributes audio = new AudioAttributes();
		audio.setCodec("libmp3lame");
		audio.setBitRate(new Integer(128000));
		audio.setChannels(new Integer(2));
		audio.setSamplingRate(new Integer(44100));
		EncodingAttributes attrs = new EncodingAttributes();
		attrs.setFormat("mp3");
		attrs.setAudioAttributes(audio);
		attrs.setDuration(30.0f);
		attrs.setOffset(0f);
		Encoder encoder = new Encoder();
		try {
			encoder.encode(source, target, attrs);
		} catch (IllegalArgumentException | EncoderException e) {
			e.printStackTrace();
		}
	}