Granularity of BeSweet -split

[jweathers7]

What is the granularity for BeSweet's -split functionality? I understand that you can specify up to the millisecond, but I'm getting strange results when I try to correct some silence problems in my AC3 file.

I have six small 3.008 second WAV files that I encode into one 5.1 AC3 file. When I use BeSweet and ac3enc to encode the file it appears to truncate the last 5.333 ms of audio, insert 5.333 ms of silence at the beginning of the AC3 file, invert the waveform of the individual WAVs, and cut the volume in half.

I have attempted to get around these issues by doing the following before encoding:
1) Inverting my individual WAV files
2) Boosting my individual WAV files by +6 dB
3) Adding 4.667ms of silence to the start of each WAV
4) Adding 1 second of silence to the end of each WAV

The result is that I get a AC3 file that is almost correct. However, it has precisely 10ms of silence at the beginning and a little less than a second of silence at the end of the AC3.

When I then try to trim these silences from the AC3 file using BeSweet, I get a file that is the correct length of time, but it is not the correct interval for some reason with the result that a small bit of audio from the beginning is missing and a little bit of silence remains at the end.

I used the following command:
BeSweet -core( -input ./AOTC04-new.ac3 -output ./AOTC04-corrected.ac3 -payload ) -split( -start 0.01 -end 3.018 )

I did an experiment with this command:
BeSweet -core( -input ./AOTC04-new.ac3 -output ./AOTC04-corrected.ac3 -payload ) -split( -end 0.01 )

The result was an AC3 file of length 0.064 ms instead of one of the desired length of 0.01.

I also have noticed that when I use BeSplit, the timestamps at which it makes the cuts are almost never precisely the timestamps that I specify on the command line.

So what are the limitations of the granularity when working with AC3 files?

[tebasuna51]

An ac3 (48 KHz) is a sequence of frames (header and data) of 32 ms. Then, for any splitter, the granularity is 32 ms.

For this, I say you in another thread:
"try to add 26.667 ms at the beginning of wav, an after cut the first 32 ms frame"

A correct ac3 always have a length multiple of 32 ms. Any truncated frame is rejected because there are two CRC's (at beginning and at the end of the frame) to verify the frame integrity.

To have a exact correspondence between wav and ac3 you need:
1) Create a wav with length (in ms) = X*32
2) Add at the beginning 26.667 ms, and 5.333 at end with anything
3) Encode to ac3
4) Cut the first 32 ms (the first frame)

[jweathers7]

An ac3 (48 KHz) is a sequence of frames (header and data) of 32 ms. Then, for any splitter, the granularity is 32 ms.

:thanks: :D :D :D

That makes so much more sense now!

Thank you so much for your suggestion. It solved my problem perfectly! I cannot thank you enough.

BTW, I didn't ignore what you wrote in the other thread, I just didn't understand it properly the way you phrased it.

To summarize for anyone else wishing to re-encode AC3 clips with ac3enc the method that seems to work is:
Prepend 1280 samples of silence to your WAV.
Append 256 samples of silence to your WAV.
Invert your WAV.
Boost your WAV by +6 dB.
Encode with ac3enc.
Cut the first 32ms from the resulting AC3 file.


I used the sox program for all of the pre-encoding manipulation and BeSplit for cutting the first 32ms.