cgsecurity.org

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.

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)

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?

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.

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.