我已收到一份文件，地址為https://drive.google.com/file/d/10Fqr6Ipu2J8yKU_m3-EMzsVj7XeSYEdV/view?usp=sharing。打開它從https://hexed.it/表明它可能是 mp3 檔案（根據檔案末尾的 ID3 資訊）。任務是恢復檔案頭，以便我們能夠打開它（大概在音樂播放器中）。任何線索將不勝感激。
我注意到檔案頭是空字節，因此我嘗試從工作 mp3 檔案複製起始位元組。也嘗試將帶有清晰文字的最後幾個位元組移動到文件的開頭。這些都不起作用。
答案1
MP3 文件沒有強制標頭；它們只是一系列原始的 MPEG 音訊幀，每個幀都有自己的 4 位元組迷你標頭（A,乙）。其他一切都是額外的。 （甚至 ID3 標籤和 LAME 標頭（兩者都是後來添加的）也被偽裝成無效幀，大多數玩家現在都知道要忽略它們。）
此外，幀格式是自同步的 - 您可以在任何點剪切它，解碼器將忽略開頭的垃圾半幀，尋找同步位元0xFFF以找到下一幀的開始。這意味著您可以將 MP3 檔案的任意隨機片段丟到解碼器中，它就會播放；如果不是，那麼它很可能根本就不是 MP3 檔案。
我的結論是你的文件不是MP3；它是使用 ID3 標記格式的其他東西（罕見但並不罕見）。更重要的是，文件的結尾位看起來並不明顯相當就像 ID3 標籤一樣——許多 4 字母區塊識別碼並不像 ID3v2 的典型情況那樣以「T」開頭；在我看來，它們更像是你在分塊格式例如亞洲電影節或者WAV/RIFF（兩者確實嵌入了 ID3 標籤！），但不在 MP3 中。
（嗯，是的，ID3 標籤本身也是一種分塊格式 - 但 MP3 總體上不是，這才是重點。）
除了 IFF 及其 AIFF/RIFF 衍生品之外，還有相當多其他標記/分塊格式，例如 PNG 以及 ISO BMFF（用於 MP4/HEIF/AVIF 文件）在概念上類似，但在你的文件 – LIST, INFO– 是明顯的RIFF，用於各種與Windows 相關的格式：.wav 用於音頻，.avi 用於視頻，.ani 用於動畫滑鼠遊標等data。
在這些 RIFF 子格式中，IART（藝術家）、ICRD（日期）、IGNR（流派）、id3␣（嵌入 ID3 標籤）區塊是 WAV 檔案的典型區塊。缺少的是頂層RIFF塊（也許是fmt␣區塊的一部分），這會阻止玩家識別該檔案。
fmt␣與另一個 .wav 檔案相比，偏移量 0x10 確實看起來像區塊的完整內容，因此遺失的前八個位元組應該如下所示：
00000000 52 49 46 46 __ __ __ __ 57 41 56 45 66 6d 74 20 |RIFF____WAVEfmt |
…空白部分是頂層區塊的長度（或 0xFFFFFFFF 表示「整個檔案」）。整體結構應該是這樣的：
RIFF[WAVE]
├─fmt␣ (PCM S16LE)
├─data (~Never gonna give you up~)
├─LIST[INFO]
│ ├─IART = "GCTF"
│ ├─ICRD
│ └─IGNR = "Drum & Bass"
└─id3␣ (embedded ID3, not RIFF-format)
├─TPE1 = "GCTF"
├─TDRC
└─TCON = "Drum & Bass"
如果您嘗試修復標頭，請使用fq檢查它（這也適用於實際的 MP3 檔案和其他常見格式）：
$ fq . test.wav
$ fq .chunks[] test.wav
$ fq .chunks[2].chunks[] test.wav
或者，由於您確實擁有包含整個 PCM 資料（長度為 4 位元組）的整個data區塊，因此僅提取該部分並透過強力嘗試各種原始 PCM 格式可能會更容易（沒有那種方法）多種組合）。