MP3 stream not copied *losslessly* with `-c:a copy`

[TheBigBadBoy]

Summary of the bug: When copying MP3 streams to a new file, the MP3 stream in the decoded new file does not match the input one (streamhash).
How to reproduce:

% ffmpeg -i stripped.mp3 -c:a copy out.mp3
% ffmpeg -v warning -i stripped.mp3 -f streamhash -
0,a,SHA256=ab1e0a0724ec4fae47c483073550723c74ad29bf6b79a93fc0861c0603ffdec4
% ffmpeg -v warning -i out.mp3 -f streamhash -
0,a,SHA256=7deac27714db19d69767c196b3d2a728e2c5dc3291351f117e5cf01b952ff16b


ffmpeg version n6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
built with gcc 13.2.1 (GCC) 20230801

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[TheBigBadBoy]

I didn't know the filesize limit is 2.5MB.

Here is the link to the file stripped.mp3 (7MB): ​https://mega.nz/file/9qI03IxB#pcdXc3kPvmpGfueIjsixipCsASkwfD8uX12WtFutIpU

[mkver]

The file has a lot of discard padding at the end: 383 samples of the penultimate frame and all samples (1152) of the last one. These 383 samples cause the difference between your file and the remuxed file.
Sample uploaded to ​https://streams.videolan.org/ffmpeg/incoming/10995/

[Balling]

This a duplicate: #9755. The gapless information gets destroyed in some cases as in during -c copy and in some race cases where there is a specific amount of samples.

[Balling]

Duplicate indeed. Now in both cases SHA256=ab1e0a0724ec4fae47c483073550723c74ad29bf6b79a93fc0861c0603ffdec4 is printed.