Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Mp3DirectCut or source file problem? (Read 6860 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Mp3DirectCut or source file problem?

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?

Mp3DirectCut or source file problem?

Reply #1 –
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):

Quote
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 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.
This is HA. Not the Jerry Springer Show.

Mp3DirectCut or source file problem?

Reply #2 –
Quote from: Robertina on
I checked these files then with foobar2000's File Integrity 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.

Mp3DirectCut or source file problem?

Reply #3 –
I couldn't agree more with you, mjb2006.

Quote
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.
This is HA. Not the Jerry Springer Show.

Mp3DirectCut or source file problem?

Reply #4 –
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.

Mp3DirectCut or source file problem?

Reply #5 –
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.
This is HA. Not the Jerry Springer Show.

Mp3DirectCut or source file problem?

Reply #6 –
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.

Mp3DirectCut or source file problem?

Reply #7 –
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 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 thread.
This is HA. Not the Jerry Springer Show.