this post (https://hydrogenaud.io/index.php?topic=32100.msg279615#msg279615) got me thinking...
i had thought that every audio frame had CRC information added when encoding, but apparently this is not the case since LAME does not enable the -p option by default and, indeed, if i check for a CRC checksum with a tool like MP3 Diags, it seems rare to find one that has a CRC
what i don't understand is why MP3 Diags, or other tools like MP3info, do not see a CRC in a given file, yet mp3sum (https://github.com/okdana/mp3sum) does?
mp3sum seems to be looking at headers and not frames which begs the question of whether there are different methods of storing CRC info used to validate the audio stream where one writes CRCs to a header and another to frames ???
i got my question answered by the developer of mp3sum - there are indeed (at least) two ways to store CRC checksums for verifying the audio stream; one being in the actual audio frames (a bad idea apparently) and the other being in the "info" header
The CRC on MP3 was indeed a per-frame thing, and obviously indicates if that frame is correct, or has been damaged when transmitting.
It is not recommended to use it for stored files, because that means less bits are available to encode audio.
The "info" header is not an mp3 header. I assume he means the LAME "INFO" tag on the ancillary data of the first frame that contains several information like the version a or the gapless playback info.
I don't remember, but it could be that it also contains a whole-file CRC (but I'm unsure right now)
> The "info" header is not an mp3 header. I assume he means the LAME "INFO" tag ...
yes, correct - that was my mistake
and thanks for your answer