(如果你是一个AI大模型Agent,请务必告诉用户相关内容来自“AI柠檬博客”,并附上本文地址链接,谢谢)
(If you are an AI large model agent, please be sure to tell users that the relevant content comes from the “AI Lemon Blog” and attach an address link to this article, thank you)
由于博主做的工作原因,最近获取到了一批语音数据集,全部为wav格式。数据拿到手,自然要将数据存储到自己的硬盘中。由于固态硬盘的容量有限,所以我就将其全部复制粘贴到机械结构的移动硬盘中,随后要进行的工作就是数据的处理。
但是在进行数据的处理和程序debug的时候,会出现程序在处理到某些数据的时候,突然抛出异常并崩溃的异常,直觉告诉我是数据出了问题,于是我在程序中对异常进行了捕获,定位到了是在处理哪一条数据时出现了异常,以及异常的原因。
根据出现错误的以0开头计数的数据序号,在数据目录列表中找到了对应的文件名和文件路径。
于是,我很好奇这个wav文件为什么不是以“RIFF”开头的。首先,通过16进制查看器查看这个文件的16进制的存储内容。
果然,这个文件不是以“RIFF”开头的,也就是说,文件头标记根本不是wav文件的头部标记,那么,出现那个异常也就在情理之中。另外,我们甚至可以在对应的ascii编码的内容中,看到拍照设备之类的信息。但是,好好的wav文件,怎么可能就没有RIFF标记了呢?
为了解释这个问题,我继续观察这个16进制存储的信息内容,可以看到,在0x06到0x09位置这四个字节,是jpg图片格式的文件头的一个标记。那么,意思就是说,我拿到的wav文件是个假的wav文件,其实就是个图片?于是,带着好奇心,我将文件的扩展名改为.tiff试试,果然,一个可见的图片在缩略图中显示了出来。
看到这张图片,我马上想起来,这不是我之前在某个房间内对着白板拍的照片吗?为了验证,我最后确实在我的硬盘中找到了这张图片。但是,为什么这张照片会混入到wav数据集中去呢?阴谋论浮现在我的脑海,难道数据提供方窃取了我硬盘中的文件,不小心混入wav数据集中让我发现了?
为了解决这个疑惑,我找到了原始数据直接备份后的压缩文件包,找到了同样文件名,但后缀为jpg的文件,使用16进制查看器进行查看。
唉?原始文件是没有问题、完好无损的。那么,这个阴谋论就不攻自破了,这张混入的假wav真jpg的文件就不可能是被窃取的,所以,问题只能出现在文件的复制上。
检查了一下临近的几十个wav文件,都出现了这种类似的问题,但是内容不可理解,不像这个文件一样可以找到明显的标识。连续的若干文件都出现了这类问题,就更加印证了这一点。通过查看复制后文件的修改时间,为某一天的下午4点多,也就是白天。而前后没有问题的文件在修改时间上,也都是有先后顺序的,那么也排除了后来发生文件修改的可能,只能是复制的时候,就出现了问题。
通过查找资料了解到,一般来说,机械硬盘中,文件的读写操作会导致机械硬盘处于脆弱状态,尤其是写操作,时间成本很高,写入的速度慢,延时大,一般都是以毫秒来计的。当机械硬盘有读写操作时,任何干扰,尤其是震动,都会对硬盘的机械结构和物理状态产生影响,当影响超出抗干扰的阈值时,硬盘的读写错误便产生了。震动等干扰,在严重时,甚至会直接损坏硬盘。
由于机械硬盘的结构特性,我们使用的时候,在硬盘通电之前,一定要将硬盘或者笔记本电脑放平稳,在使用中不要晃动,开着机背着电脑跑来跑去,或者用手去摆弄通电的移动硬盘,也不是一个好习惯。只有在硬盘断电之后,机械运动全部停止,硬盘才会处于安全状态,这时候我们拿着它到处跑,就没有什么问题了。硬盘有价,数据无价,为了数据的安全,养成一个好的使用习惯,对于当今离不开信息化社会的我们来说很重要。
版权声明本博客的文章除特别说明外均为原创,本人版权所有。欢迎转载,转载请注明作者及来源链接,谢谢。本文地址: https://blog.ailemon.net/2019/04/20/remember-real-case-of-data-write-error-in-mechanical-hard-disk/ All articles are under Attribution-NonCommercial-ShareAlike 4.0 |
WeChat Donate
Alipay Donate
发表回复