MP3 files and fragmentation

Using PhotoRec to recover lost data
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
Locked
Message
Author
fabml
Posts: 3
Joined: 02 Feb 2019, 21:40

MP3 files and fragmentation

#1 Post by fabml » 02 Feb 2019, 21:45

Hi,
I'm using Photorec to recover a big number of MP3 files. They are stored in a drive that has not heavy fragmentation, but I think that it is unavoidable. So what happens when a file is fragmented? Will the file be incomplete or will it contain a piece of the contiguous file? They are very long files and I can't listen them individually.
Can I know which file is incomplete or not recovered by report.xml file?

Thank you for the support and for this great software.

Sponsored links

User avatar
cgrenier
Site Admin
Posts: 4994
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: MP3 files and fragmentation

#2 Post by cgrenier » 03 Feb 2019, 10:53

mp3 is a streaming file format, so PhotoRec can not see the difference between a truncated music or the whole music.
If photorec recovers 3 mp3 files for a single music, you can play them in succession or even concat them together (Under Windows: type file1.mp3 file2.mp3 file3.mp3 > music.mp3)

fabml
Posts: 3
Joined: 02 Feb 2019, 21:40

Re: MP3 files and fragmentation

#3 Post by fabml » 04 Feb 2019, 18:36

Thank you for the answers.
I'm worried about the eventuality that a file could contain a piece of another audio file. For example, if we have two files (a.mp3, b.mp3) and some a.mp3's fragment is written AFTER b.mp3 starting, but before its ending, a.mp3 will be truncated or will contain b.mp3 pieces?
In my situation, I can compare file sizes (but I can't perform an MD5 comparison): Same size and playable file could mean that the file is ok?

User avatar
cgrenier
Site Admin
Posts: 4994
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: MP3 files and fragmentation

#4 Post by cgrenier » 03 Apr 2019, 06:09

It's more common to have splitted mp3 than concatenated mp3. You may have a playable file even if it misses some fragment.
I don't know if the filesize can really be use to check if the file is OK.

recuperation
Posts: 362
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: MP3 files and fragmentation

#5 Post by recuperation » 03 Apr 2019, 08:44

fabml wrote:
02 Feb 2019, 21:45
Can I know which file is incomplete or not recovered by report.xml file?
See manual 11.11.
Files that are considered broken are marked by a leading "b" in the name.
fabml wrote:
04 Feb 2019, 18:36
I'm worried about the eventuality that a file could contain a piece of another audio file. For example, if we have two files (a.mp3, b.mp3) and some a.mp3's fragment is written AFTER b.mp3 starting, but before its ending, a.mp3 will be truncated or will contain b.mp3 pieces?
My answer is just a guess!

If there is no length information available a.mp3 will be truncated.
The reason is that once photorec reads the beginning of b.mp3 it notices a new mp3-header. This should stop the recovery of a.mp3.
If however photorec reads a middle cluster of file b.mp3 which does not contain file header information, it should simply append that cluster creating effectively merging file fragments from two different files.

As long as cluster number of files are always in rising order such a mix should extend the file length of a which should warn you based on your additional length information.
In my situation, I can compare file sizes (but I can't perform an MD5 comparison): Same size and playable file could mean that the file is ok?
It is not a guarantee but the probability of an unbroken file rises.

Locked