[GH-ISSUE #144] Clarification Needed on SHA256 Hash Differences and Metadata Variations in Copied Tracks #131

New issue

Open

opened 2026-02-27 15:48:23 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 15:48:23 +03:00

Owner

Originally created by @AndyBogle1 on GitHub (Sep 18, 2025).
Original GitHub issue: https://github.com/Rafiuth/Soggfy/issues/144

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

$ sha256sum ~/Soggfy_Test/*
e3d1ef4ce1f947a582e3da8d389ea9c6d7823b1fe3651386999332e20d0938ad  ./Track_Copy_1.ogg
ed41eeb0ac432872a4476d24207c473d4d123d1372470ec1221eac42210a8599  ./Track_Copy_2.ogg

Preliminary Investigation
When analysing both copies with MediaInfo, I noticed the following discrepancies:

Writing Application: Different versions (Lavf62.3.100 vs Lavf61.7.100).
Embedded Lyric Timestamps: Slight differences in timestamps for the same lyric (e.g. [02:39.39] vs [02:39.13]).
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:

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

Are differences in writing application, lyric timestamps and Audio ID expected behaviour?
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?

Originally created by @AndyBogle1 on GitHub (Sep 18, 2025). Original GitHub issue: https://github.com/Rafiuth/Soggfy/issues/144 **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?

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/Soggfy#131

No description provided.

Rows
Columns