How does photorec decide on the end of file for mp3 files?
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
-
- Posts: 1
- Joined: 22 Aug 2020, 01:55
How does photorec decide on the end of file for mp3 files?
I notice a lot of my mp3 files are fully intact, but a lot are cutoff (with a lot of them having definite filesizes of 65537 KB and 81920 KB and 32769KB and ESPECIALLY 8193 KB
- cgrenier
- Site Admin
- Posts: 5432
- Joined: 18 Feb 2012, 15:08
- Location: Le Perreux Sur Marne, France
- Contact:
Re: How does photorec decide on the end of file for mp3 files?
PhotoRec parses the mp3 chunks and ends the recovery when the stream stops.
The 8193 KB mp3 may be fragments from a fragmented file or part of a video file...
The 8193 KB mp3 may be fragments from a fragmented file or part of a video file...
-
- Posts: 50
- Joined: 07 Jun 2020, 20:38
- Location: France
Re: How does photorec decide on the end of file for mp3 files?
What do you mean by “parses the mp3 chunks”, is it aware of the specific structure of the MP3 file format, or does it merely stop at the next identified file signature ?
As I explained in-depth here, I've observed that quite commonly, a valid and contiguous video file can be recovered with many “holes”, caused by the detection of false MP3 signatures, and so there are dozens of 3KB MP3 files, obviously unreadable, while the chunks of the video file which come after each false MP3 are simply attached to the previous chunk (I verified this by comparing recovered video files with their valid counterparts recovered by filesystem based recovery). Obviously this wouldn't happen if the program was able to analyse the inner structure of a MP3 data stream, as it would notice that there is none in such a situation.
As I explained in-depth here, I've observed that quite commonly, a valid and contiguous video file can be recovered with many “holes”, caused by the detection of false MP3 signatures, and so there are dozens of 3KB MP3 files, obviously unreadable, while the chunks of the video file which come after each false MP3 are simply attached to the previous chunk (I verified this by comparing recovered video files with their valid counterparts recovered by filesystem based recovery). Obviously this wouldn't happen if the program was able to analyse the inner structure of a MP3 data stream, as it would notice that there is none in such a situation.