Clarification Needed on SHA256 Hash Differences and Metadata Variations in Copied Tracks

#144 · open · 0 comments

View on GitHub ↗

AndyBogle1

**Issue** The README mentions that the process "results in an exact copy of the original files served by Spotify". However, when attempting to save the same track multiple times, the SHA256 hashes of each `.ogg` file differ. **Example** ```bash $ sha256sum ~/Soggfy_Test/* e3d1ef4ce1f947a582e3da8d389ea9c6d7823b1fe3651386999332e20d0938ad ./Track_Copy_1.ogg ed41eeb0ac432872a4476d24207c473d4d123d1372470ec1221eac42210a8599 ./Track_Copy_2.ogg ``` **Preliminary Investigation** When analysing both copies with [MediaInfo](https://mediaarea.net/en/MediaInfo), I noticed the following discrepancies: 1. Writing Application: Different versions (`Lavf62.3.100` vs `Lavf61.7.100`). 2. Embedded Lyric Timestamps: Slight differences in timestamps for the same lyric (e.g. `[02:39.39]` vs `[02:39.13]`). 3. Audio ID Field: A mismatch in the ID field (e.g. `3083576650 (0xB7CBA54A)` vs `532621881 (0x1FBF2A39)`). Thankfully, `diff <(fpcalc Track_Copy_1.ogg) <(fpcalc Track_Copy_2.ogg)` returned no output, suggesting that the differing SHA256 hashes are likely due to metadata differences rather than changes in the actual audio data. Additionally, the SHA256 hashes of the extracted audio data are identical, as confirmed by the following: ```bash ffmpeg -v error -i Track_Copy_1.ogg -map a:0 -ar 44100 -ac 2 -f s16le - 2>/dev/null | sha256sum ffmpeg -v error -i Track_Copy_2.ogg -map a:0 -ar 44100 -ac 2 -f s16le - 2>/dev/null | sha256sum ``` **Questions** 1. Are differences in writing application, lyric timestamps and Audio ID expected behaviour? 2. Can you confirm that the audio data of the `.ogg` files will be the same across runs, and that any differences are purely related to metadata?

Comments