I sometimes use Mp3DirectCut to divide mp3 files into shorter, easier to deal with pieces. I've done this with perhaps six or ten books so far, always without any difficulty. Today, when I started to use it on another book, I got a Warning dialogue at the end of the first "Save split" operation. The message is
While Saving 8 files(s) 15 re-synch(s) occurred
I repeated on files # 2 and 3 of the book and got the same result. The number of re-synchs varies by source file but is consistent if I re-do the same file. I tested a file from another audio book and everything was normal.
Does anyone know what this means?
What is there about the files of this book that lead to this?
Will there be symptoms when someone listens to the book?
I have had that situation in rare cases with some VBR files in the past. In mp3DirectCut's FAQ.htm, included in the installer, I found hints like the following (here citied from the current version):
Q : I got 'Re-syncs' on saving, what do they mean?
A : That the program could not find a frame* header where it was expeceted. It was necessary to search for the file position of the next header. This can happen in corrupted files, at cut or paste positions, at a file end or in some cases within VBR files. Often a Re-sync does not mean that anything went wrong. But sometimes, some frames in the output file may be skipped. As not all possible error and corruption constellations are examined, it cannot be excluded that the program can hang or crash in some sync fail situations.
(Above this excerpt, you can find a second question dealing with the re-sync-topic).I checked these files then with foobar2000's File Integrity Verifier (http://www.foobar2000.org/components/view/foo_verifier) and got some warnings.
With a right-click on the files in question and invoking either "Utilities > Fix VBR MP3 header" or "Utilities > Rebuild MP3 stream" or both before editing them with mp3DirectCut I have always been able to solve that issue. Perhaps it will work for you as well.
I checked these files then with foobar2000's File Integrity Verifier (http://www.foobar2000.org/components/view/foo_verifier) and got some warnings.
With a right-click on the files in question and invoking either "Utilities > Fix VBR MP3 header" or "Utilities > Rebuild MP3 stream" or both before editing them with mp3DirectCut I have always been able to solve that issue. Perhaps it will work for you as well.
"Solve" only in the sense of making the warnings go away by deleting junk data that was found where valid frames were expected. This inter-frame junk gets skipped during playback anyway, so removing it from the file has no audible benefit. If the junk data was something extra added into the file somehow, then no problem, the rebuilt version is structurally ideal. But if the junk is corrupted frame data, it was never playable, and deleting it is not really repairing the problem. Either way, the rebuilt file is only superficially better than the corrupt original, IMHO.
I couldn't agree more with you, mjb2006.
removing it from the file has no audible benefit
Please note that I didn't claim something like that - and this not only because of TOS #8.
Using foobar2000, I ran
Verify integrity
on several of the files. Among other complaints it reported that the file could not be decoded properly.
Then, again through foobar2000, I ran
Rebuild mp3 stream
on each source file.
I listened to the full 70 some minutes of one file. It played without any problems.
All the files were run through mp3DirectCut to sub divide them into more convenient lengths. There were no more complaints.
For the sake of completeness I would like to add that the File Integrity Verifier reported for some edited VBR MP3s an incorrect length in my case. The fb2k command "Fix VBR MP3 header" corrected that, too.
I use mp3DirectCut only occasionally, but based on my experience I do verify all editings with the FIV.
Using Verify integrity after Rebuild mp3 stream produced a message about incorrect length. These files, however, are CBR, and there is no "fix header" utility for that, as least as far as I see.
Indeed its name would not let assume it, but according to my experience the "Fix VBR MP3 header"-function can also be applied to CBR files and worked, at least for me, even in very specific (http://www.hydrogenaudio.org/forums/index.php?showtopic=83344&hl=) cases.
You could use copies of your files in question in order to check risk-free what results you would get.
Maybe you are also interested in reading this (http://www.hydrogenaudio.org/forums/index.php?showtopic=95297) thread.