BeSweet AC3 joining problems

[pirata]

What I am trying to do: to fix and merge 2 ac3 files. They were extracted from an AVI that was cut with Nandub, so a ac3 frame is incomplete (either at the end of the first part or at the beginning of the second part). I tried first with BeSplit, and it would fix each file separatedly, but when I tried joining, all I got were the help tips. The comand used looked like:

besplit -core(-input join.lst -prefix d:\filename -type ac3 -join )

The paths and filenames in join list were I:\M1.ac3 and I:\M2.ac3 (neither strange chars nor long names; I took the idea of the .lst file from the Audio FAQ 7, read below). BeSplit would be invoked by the command but the answer would be just to show the help hints and leave. No processing done.


That's when I turned to BeSweet:

7) how can i join ac3 files ?
let's say you want to join stream1.ac3,stream2.ac3,stream3.ac3 into stream.ac3.
create a listfile. join.lst :
stream1.ac3
stream2.ac3
stream3.ac3

and then, use BeSweet :

code:--------------------------------------------------------------------------------
BeSweet -core( -input join.lst -output stream.ac3 -payload )
--------------------------------------------------------------------------------

this will also work on CBR mp3 files.
note - Since BeSweet v1.4, this process requires VOBInput.dll. get it from BeSweet's PlugIn Page.

-.-.-.-.-.-.-.-..-.-.--.-.-.-.-.-.-.-.-..-

I have followed this indications above with BeSweet 1.4 (VOBInput.dll and borlndmm.dll are also in the BeSweet directory), and the only answer I get is the help tips. No processing. The command used is exactly the same as above.

By the way: BeSweet version 1.4 does not contain neither mpglib.dll nor ssrc.dll, is that right?

Well! I am desperating. Any idea?
If nobody can help, does any body know of some utility to merge ac3s?

Cheers, Pirata

[pirata]

Workaround: you can fix the ac3s with BeSliced, and then join them with DVTool. The file plays fine. I just wonder how do these file-merging tools manage, in order to merge any file? I mean, does DVTool know the structure of any file, in this case ac3, and thus makes a proper merging -what about timestamps of ac3 frames? How are broken frames treated?-, or it simply appends the second file -with header and all- to the end of the first file? In that case, why does such a messed up file work so good?

Cheers, Pirata

[pacohaas]

:logfile:

are you sure your paths are correct for your .lst, input, and output files? You may consider using the complete path if you are not already, also please enable the logfile option and post that here.

p.s. I've changed the title of this thread to be more descriptive, try to do that in the future, and calling on DSPGuru or any other moderator in the title is also not needed.

[pirata]

Sorry about the thread title. Let's go for work:

-Input commands for BeSweet:

-core(-input I:\Join.lst -logfile I:\logfile.log -output I:\output.ac3 -payload)

-Input commands for BeSplit:

-core(-input I:\Join.lst -logfile I:\logfile.log -prefix I:\output -type ac3 -join)

-Contents of Join.lst:

I:\M1.ac3
I:\M2.ac3

-The logfile is empty in both tries. No output is generated.

-By the way: BeSweet version 1.4 does not contain neither mpglib.dll nor ssrc.dll, is that right?

SO: everything seems in place. They work if I don't use a .lst file (e.g. fixing a ac3), but I want to join ac3s, and I do need a .lst file to do that, don't I? So the problem must be the .lst syntax.

Any idea? Pirata

[DSPguru]

i see missing spaces after "(" and before ")" ;)

[pirata]

Yeah. That was it. I really feel stupid.

By the way, maybe somebody can help me with this a little more: the 2 ac3s I try to fix/join where muxed with 2 AVIs. Those AVIs were cut with NanDub, and there is a frame cut in the middle. One half is in the first ac3, the other half is in the second ac3. If I fix them with BeSplit/BeSliced, and then join them, what I will get is one frame padded with trailing 0s, and after that another frame which starts with 0s. I'd rather restore the stream as it was, and join that broken frame without any padding. How can I do that? Maybe if I just join the files with BeSweet without fixing them before? What will BeSweet do if it finds a broken frame followed of another broken frame that once were one and the same?


Thanks. Pirata

[DSPguru]

Originally posted by pirata
What will BeSweet do if it finds a broken frame followed of another broken frame that once were one and the same?will merge them into one.

[pacohaas]

Originally posted by pirata
-By the way: BeSweet version 1.4 does not contain neither mpglib.dll nor ssrc.dll, is that right?yes, these are now obsolete, check the readme's for the new dll's.

[pirata]

@ DSPGuru: you mean that the stream will be completely restored as it was? The other way round: can BeSweet rebuild broken frames when the first part of the broken frame is at the end of the first ac3 and the other part at the beginning of the other ac3? (sorry if I seem stupid, just wanna be sure...).

[DSPguru]

yes, it will be restorted.

[pirata]

@DSPGuru: I am trying to join these 2 ac3s in order to mux them with VirtualDub OGM mod by Cyrius. The muxing routine takes each ac3 frame and puts it in a ogm packet. It reads the stream frame by frame, so it's very sensible to broken frames (unlike the original Virtualub routines). The ac3s come in AVI files that were cut with Nandub. Nandub breaks the ac3 frame if the cut point falls in the middle of it. Cyrius told me he thought that Nandub was not so bad at cutting, and that the 2 parts of the ac3 frame should be there. He was not sure of that, though. I'd like to recover the ac3 as it was before the cut. I don't want any padding to fill the broken frame, since it will cause synch problems (even though they could be unnoticeable). I've tried several ways.

If I join the AVI files with Nandub and then extract the audio (with the same program), the resulting ac3 has some problem, since the muxing with VDub OGM fails (the ac3 sound in the OGM stops exactly at the joint point; VDub OGM reaches the broken frame at the joint point and determines there is no more ac3 data to mux, so the resting time is silence).

Then I turn to your tools, DSPGuru.

I use BeSplit to fix each ac3 (they were extracted with NanDub from the AVI containers). Then I join them with DVTool (I couldn't do it with BeSplit nor BeSweet because I did it wrong with the command options) and do muxing with VDub OGM. Results are perfect. The stream is not interrupted. The synching problems are dificult to perceive. anyway, I'd like to go a better way.

I think that maybe joining with BeSweet without fixing first will do the right job. That is what we have discussed in the last posts. You said that it would join the broken frame without padding. Well... I did it. I merged the ac3s with BeSweet without fixing. The resulting file was smaller than the one generated after fixing and merging, so I thought that the padding was not there and the broken frame had been rejoined. I muxed it with VDub OGM and... it didn't work. The ac3 audio stream stopped at the joint point.

Merging directly with BeSweet does not fix the broken frame problem.
Maybe Cyrius was wrong and a frame part is lost by Nandub when cutting. Maybe BeSweet can not deal with half frames, so padding is necessary.

I don't know what is the right thing to do, DSPGuru. Hope you can help with this.

Thanks, Pirata

[DSPguru]

if no loss was made in the cutting process, and you have two files that represents a valid stream together, the right thing to do is :
a. use BeSplit to join them into one
b. use BeSplit on the joint file and look for errors
c. post your logfile so we can see what happend.

[pirata]

Did as you told me. I joined both ac3s with BeSplit without fixing. To check for errors I used BeSplit on the joint file with the -fix option. The logfile:

BeSplit v0.82 by DSPguru.
--------------------------
Logging start : 11/03/02 , 20:17:52.

BeSplit.exe -core( -input I:\output.ac3 -prefix i:\output_fixed -type ac3 -logfile i:\logfile.log -fix )

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : I:\output.ac3
[00:00:00:000] | Output Prefix : i:\output_fixed
[00:00:00:000] +---------------------
[00:00:00:032] Stream error : Sync found after 46 bytes
[01:12:00:672] Stream error : Sync found after 1543 bytes
[02:27:07:136] | Writing i:\output_fixed01.ac3
[02:27:07:136] +---------------------
[02:27:07:136] Operation Completed !
[00:02:12:000] <-- Process Duration
Logging ends : 11/03/02 , 20:20:04.


The first ac3 is 230 MB (241.956.829 bytes) big. The second is 240 MB (252.364.476 bytes). The joint file is 471 MB (494.321.305 bytes). The joint fixed file is 471 MB (494.319.616 bytes). So something is removed!

Now this is what it happens if a fix the ac3s independently:

Logfile for the fixing of the first AC3----------------------

BeSplit v0.82 by DSPguru.
--------------------------
Logging start : 11/03/02 , 21:04:11.

BeSplit.exe -core( -input i:\m1.ac3 -logfile i:\logfile.log -prefix i:\caca -type ac3 -fix )

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : i:\m1.ac3
[00:00:00:000] | Output Prefix : i:\caca
[00:00:00:000] +---------------------
[00:00:00:032] Stream error : Sync found after 46 bytes
[01:12:00:640] | Writing i:\caca01.ac3
[01:12:00:640] +---------------------
[01:12:00:640] Operation Completed !
[00:01:19:000] <-- Process Duration
Logging ends : 11/03/02 , 21:05:30.


Logfile for the fixing of the second AC3---------------------

BeSplit v0.82 by DSPguru.
--------------------------
Logging start : 11/03/02 , 20:48:27.

BeSplit.exe -core( -input i:\m2.ac3 -logfile i:\logfile.log -prefix i:\caca -type ac3 -fix )

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : i:\m2.ac3
[00:00:00:000] | Output Prefix : i:\caca
[00:00:00:000] +---------------------
[00:00:00:032] Stream error : Sync found after 602 bytes
[01:15:06:496] | Writing i:\caca01.ac3
[01:15:06:496] +---------------------
[01:15:06:496] Operation Completed !
[00:01:20:000] <-- Process Duration
Logging ends : 11/03/02 , 20:49:47.

---------------------


Can you tell me what happened? Was there any padding? Was any broken frame found? It looks like BeSplit found and removed tha Wav Headers only. It seems there is no broken frame.

If there is no broken frame, why does the OGM muxing fail when I use the joint ac3 ripped with Nandub? (it will only have a wav header attached and no broken frame, so it should work good!)

Look at this, also:

Joint AC3
[00:00:00:032] Stream error : Sync found after 46 bytes
[01:12:00:672] Stream error : Sync found after 1543 bytes

First AC3
[00:00:00:032] Stream error : Sync found after 46 bytes

Second AC3
[00:00:00:032] Stream error : Sync found after 602 bytes

Why is there a difference in the amount of bytes when removing the second header??

I start to think that maybe Nandub puts 2 wav headers: one for the first half, one for the second. That would be the reason why the OGM muxing fails. There would be no broken frame. But 2 wav headers makes no sense. Do you know some means to test if there is a wav header in the middle of the joint ac3 ripped with Nandub?

[DSPguru]

Originally posted by pirata
Joint AC3
[00:00:00:032] Stream error : Sync found after 46 bytes
[01:12:00:672] Stream error : Sync found after 1543 bytes

First AC3
[00:00:00:032] Stream error : Sync found after 46 bytes

Second AC3
[00:00:00:032] Stream error : Sync found after 602 bytes

Why is there a difference in the amount of bytes when removing the second header?? looks like there are 941bytes of leftovers at the end of the first file.

I start to think that maybe Nandub puts 2 wav headers: one for the first half, one for the second. That would be the reason why the OGM muxing fails. There would be no broken frame. But 2 wav headers makes no sense. Do you know some means to test if there is a wav header in the middle of the joint ac3 ripped with Nandub? i believe you're right, and there's another wav header stuck in the middle of your file.
please cut the very first part of the second stream using any binary splitter and attach in here.

[pirata]

OK. Tell me first if this steps are the ones wou want me to take:

0-I rip each ac3 from the orginal AVI containers. With Hexworks, I cut the last 1000bytes of the first ac3 (to see the 941bytes of leftovers). I also estract the first bytes of the second ac3, which make up a wav header for sure. By the way: how big is a wav header? How many bytes should I extract?

1-I merge the AVIs with NanDub and extract the joint ac3. This ac3 could have another wav header right in the middle (if that's true, Nandub is real a bad tool!). I take the size of the first ac3 half, and go exactly to that offset into the Nandub-joint ac3. I go back 1000bytes and extract a chunk big enough to contain those 1000bytes plus the wav header (if there was any). With this data and the data we extracted from the partial ac3, we could be able to identify the header and the leftovers.

Note: the "leftovers" are the last 941 bytes of the first ac3, which are removed by BeSplit when fixing the joint file (which was merged with BeSplit), but are not detected when the first ac3 is fixed with BeSplit.

If this you agree with, I will proceed and attach the resulting files in the thread.

[DSPguru]

you need to use an hexa editor to remove the first 46bytes from (the beginning of) both files, then join them into one with BeSplit and then fix it with BeSplit.

good luck!

[Bad Joker]

i got something similar

i have here 2 ac3 files extracted from a divx5 dvdrip (heat) and i wanted to join them to use them with another heat rip.

with besweet i couldn't join them, he begins to copy and then after the first file is copied, he stops, so the result has the exact size like the original 1st ac3 file

with beslpit it worked fine now, here are the logs:

BeSweet v1.5b4 by DSPguru.
--------------------------
Using azid.dll v1.8 (b825) by Midas (midas@egon.gyaloglo.hu).
Using hip.dll v1.13 by Myers Carpenter <myers@users.sf.net>
Using VOBInput.dll v1.2 by DVD2SVCD (http://www.notrace.dk)

Logging start : 11/06/02 , 00:04:35.

BeSweet.exe -core( -input join.lst -output heat.ac3 -payload -logfile BeSweet.log -join -prefix )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : heat1.ac3
[00:00:00:000] | Output: heat.ac3
[00:00:00:000] +------- AC3ENC ------
[00:00:00:000] | Bitrate method : CBR
[00:00:00:000] | AC3 bitrate : 384
[00:00:00:000] | Channels Mode : 5.1
[00:00:00:000] | Error Protection: Yes
[00:00:00:000] +---------------------



BeSplit v0.9b3 by DSPguru.
--------------------------

Logging start : 11/06/02 , 00:17:08.

BeSplit.exe -core( -input join.lst -logfile BeSplit.log -prefix heat.ac3 -type ac3 -join )

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : join.lst
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] | Channels Count: 3, Bitrate: 32kbps
[00:00:00:000] | Output Prefix : heat.ac3
[00:00:00:000] +---------------------
[ 0] Proessing heat1.ac3..
[ 234685486] Proessing heat2.ac3..
[ 471449180] <-- Output file length
[00:00:00:000] +---------------------
[00:00:00:000] Operation Completed !
[00:01:37:000] <-- Process Duration
Logging ends : 11/06/02 , 00:18:45.

the join.lst file:
####################
heat1.ac3
heat2.ac3
####################

i tried to reencode the ac3 files with ac3machine and i tried to remove the wave header like you described in you faq, but i didn't work.

maybe you can tell me the reaseon

problem is solved now, maybe you are intrested in the "bug"

[pirata]

I am sorry for the late. I've had some bad times with my PC.

The AC3-joining problem remains unsolved on my side.

@DSPGuru

you need to use an hexa editor to remove the first 46bytes from (the beginning of) both files, then join them into one with BeSplit and then fix it with BeSplit.

I tried that way and it didn't work. That's what I did: I had accidentally removed the ac3 files, so I had to rip them again. I used this time VirtualDub 1.4.10 (actually, the Cyrius OGM modification), in order to work with a tool that somebody still maintains (Avery Lee/Cyrius). I ripped both ac3s and fixed them with BeSplit in order to make sure how big the RIFF headers were. These are the logs:


First AC3:

BeSplit v0.82 by DSPguru.
--------------------------
Logging start : 11/11/02 , 15:08:02.

BeSplit.exe -core( -input i:\m1.ac3 -logfile i:\logfile1.log -prefix i:\m1_fixed -type ac3 -fix )

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : i:\m1.ac3
[00:00:00:000] | Output Prefix : i:\m1_fixed
[00:00:00:000] +---------------------
[00:00:00:032] Stream error : Sync found after 58 bytes
[01:12:00:640] | Writing i:\m1_fixed01.ac3
[01:12:00:640] +---------------------
[01:12:00:640] Operation Completed !
[00:01:12:000] <-- Process Duration
Logging ends : 11/11/02 , 15:09:14.

First of all, the size of the header changes with respect to the one we had using NanDub. I guess it doesn't matter. More importantly, the original file size was 241956841Bytes. The fixed file was 241955840Bytes long, so 1001 bytes where removed, instead of 58Bytes. Curious, huh?


Second AC3:

BeSplit v0.82 by DSPguru.
--------------------------
Logging start : 11/11/02 , 15:09:32.

BeSplit.exe -core( -input i:\m2.ac3 -logfile i:\logfile2.log -prefix i:\m2_fixed -type ac3 -fix )

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : i:\m2.ac3
[00:00:00:000] | Output Prefix : i:\m2_fixed
[00:00:00:000] +---------------------
[00:00:00:032] Stream error : Sync found after 614 bytes
[01:15:06:496] | Writing i:\m2_fixed01.ac3
[01:15:06:496] +---------------------
[01:15:06:496] Operation Completed !
[00:00:58:000] <-- Process Duration
Logging ends : 11/11/02 , 15:10:30.


As you can see, the header size is again slightly different as when using NanDub. In the second ac3, the header seems to be much bigger. Maybe a broken frame is already removed there. Can a RIF header be 614 bytes long? The original file size was 252364488Bytes, and after fixing 252363776Bytes. 712Bytes had been removed, instead of 614, as BeSplit declares.

Summing up, the total amount of bytes removed is 1001+712=1713Bytes.

If the fixed ac3s are joined with BeSplit, the resulting file size is 494319616Bytes, and if the resulting file is fixed again, the log informs of no stream errors.

So: I did 2 things there.

1-I joined the original files (without fixing), and then fixed the resulting file (always with BeSplit). The log:

BeSplit v0.82 by DSPguru.
--------------------------
Logging start : 11/11/02 , 15:53:45.

BeSplit.exe -core( -input i:\m0.ac3 -logfile i:\logfile3.log -prefix i:\m0_fixed.ac3 -type ac3 -fix )

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : i:\m0.ac3
[00:00:00:000] | Output Prefix : i:\m0_fixed.ac3
[00:00:00:000] +---------------------
[00:00:00:032] Stream error : Sync found after 58 bytes
[01:12:00:672] Stream error : Sync found after 1555 bytes
[02:27:07:136] | Writing i:\m0_fixed.ac301.ac3
[02:27:07:136] +---------------------
[02:27:07:136] Operation Completed !
[00:02:15:000] <-- Process Duration
Logging ends : 11/11/02 , 15:56:00.

The initial file size was 494321329Bytes. The final size was 494319616Bytes. 1713Bytes are removed, but only 1613Bytes are declared in the log. The real amount of bytes removed and the final file size are the same as when joining the fixed ac3s, so I consider that both processes provide the same file, and that the broken frame gets lost, and that synch problems will probably appear.


2-As DSPGuru told me, I tried to remove the RIFF header by myself and the join/fix with BeSplit. The header size seems to be 58 bytes (first A3 log), so I remove that exact amount of bytes from the beginning of each partial ac3, in the hope that BeSplit will be able this time to recognize the broken frame and fix it. After joining the header-less ac3s I fix the resulting file with BeSplit. Here is the log:

BeSplit v0.82 by DSPguru.
--------------------------
Logging start : 11/08/02 , 02:02:35.

BeSplit.exe -core( -input i:\m0.ac3 -logfile i:\logfile3.log -prefix i:\m0fixed -type ac3 -fix )

[00:00:00:000] +------- BeSplit -----
[00:00:00:000] | Input : i:\m0.ac3
[00:00:00:000] | Output Prefix : i:\m0fixed
[00:00:00:000] +---------------------
[01:12:00:672] Stream error : Sync found after 1497 bytes
[02:27:07:136] | Writing i:\m0fixed01.ac3
[02:27:07:136] +---------------------
[02:27:07:136] Operation Completed !
[00:01:48:000] <-- Process Duration
Logging ends : 11/08/02 , 02:04:23.

So: the same results appear. 1497 is 1555-58. That migh mean, that the headers were actually removed by me, but BeSplit was not able to join the frame. It could also happen that the second header has a size different from 58. In the fixing of the second ac3, 614Bytes are removed. Maybe a part of it is a big RIFF header and the rest a broken frame. I can't recognize the boundaries of a RIFF header with an HEX editor, so I'll attach a zip file with the first 2KB of the second ac3. I'll include the first 2KB of the first ac3 for comparison purposes. I hope that DSPGuru or somebody else will find the header boundaries easily...

OK: I am having troubles with my HEX editor and don't have much time right now. I'll post the zip file tonight.

Cheers, Marc

[pacohaas]

i don't think you've mentioned the dvd/region you are using, seeing all this trouble makes me want to check it out sometime, you mind divulging this information?

edit: ahhh, i'm sorry, i forgot we were extracting from AVI files

[DSPguru]

Originally posted by pirata
1497 is 1555-58. Originally posted by pirata
Joint AC3
[00:00:00:032] Stream error : Sync found after 46 bytes
[01:12:00:672] Stream error : Sync found after 1543 bytes 1497 is also 1543-46.

as you can see, it seems that the ac3 stream wasn't splitted correctly.
if i'm not mistaken, your stream is ac3, 3/2, 384kbps, and therefore the frame size should be : 1536 bytes.
i guess that the best thing would be to :
1. fix both streams with BeSplit
2. add 32ms of silence to second stream using latest BeSweet
3. join with BeSplit

btw,
wave header ends exactly 4 bytes after 'data' appears.

[pirata]

@DSPGuru:

Hey let's not surrender! I guess there has to be something at the end of the first ac3 that BeSplit finds strange. Thus, when you fix that first ac3, it removes not only the header, but also circa 1000Bytes from the end, even though it doesn't inform of it. If I send you the last 2KB of the first ac3, will you have a look at it?


Bye!


PS:
I use the fact of being posting with the maker of BeSplit to ask: don't you think that BeSplit should give account on every single byte it removes?? I don't find it right when it changes things and does not inform of it. Moreover, more insight in the operated changes will be definitely a plus!

[DSPguru]

Originally posted by pirata
If I send you the last 2KB of the first ac3, will you have a look at it?attach a zip file with 2kb with the end of the 1st and 2kb of the start of the 2nd.


don't you think that BeSplit should give account on every single byte it removes??Basicly, in this mode, BeSplit is seeking only for AC3 frames and doesn't suppose to recognise "garbage" between them ;).

however, when i will be introducing full batch processing support in BeSplit, wave headers would be recognised and ignored.

[pirata]

Here you are. The final chunk of the first ac3 (M1_trimmed.ac3) is 2 bytes bigger thatn 2KB. I cut it with a Hex editor I didn't use before. If there is any problem, just told me.

I do believe there is something at the end of each ripped ac3 part, which is placed there by VDub. You are pretty sure that if a broken ac3 frame was at the end of the first ac3 part, and the remaining of that frame was at the beginning of the second part, they would be joined by BeSplit. That clearly doesn't happen. To wrap up: either there is something in the end of the first a3 file, or the remaining of the broken frame is not at the beginning of the second ac3 file.

By the way: don't you think that many many people will be having a similar problem to the one we are discussing? I think we are trying to solve something more general than just my problem. However, maybe nobody gives a damn about broken frames...

Greetings, Pirata

[DSPguru]

from first observation, it seems hopeless. the framesize seem to be 1792bytes, while the payload is much smaller.

[pirata]

Could you please shed some light on those technical words?


Pirata

[pirata]

Are you still there?

[DSPguru]

Originally posted by pirata
Could you please shed some light on those technical words?i said that it seems like the size of the broken frame suppose to be 1792 bytes, while we don't have that amount of bytes to reconstruct it.

for a fullproof answer, i suggest that you make a bigger snapshots of the files. something like 10kb each instead of 2kb.

[pirata]

Could you explain what does payload mean?
The ac3 chunks you asked are in the attachement.

[pirata]

Could you explain what payload means?
See the attachement.

[DSPguru]

tested again. seems hopeless.

[pirata]

Could you explain yourself a little bit more? (payload...etc)

[DSPguru]

the file seem to be an AC3 5.1 448kbps 48khz stream.
this stream is built of ac3 frames. each frame has a size of 1792 bytes.

from what it seems, there is no way to find those 1792bytes between the last valid frame in the first file to the first valid frame in the second file.

again, i think a single frame delay would do a good job.

[pirata]

OK. I thank you. We can finally give up, I guess.

By the way, how long is a frame with that stream specs? I am thinking that I maybe could delay the whole ac3 stream by (frame length)/2 ms, so that I could reduce the negative delay in the second half by introducing a less noticeable positive delay in the first half. If I don't do so, the negative delay (audio sounding too early because the loss of 1 frame) in the second half would be (maybe) too noticeable. But I need to know the length of 1 frame with that stream specs.

What do you think about this?

[DSPguru]

single frame represents 32msec.

it is impossible to assert half frame delay without re-encoding the whole stream, but i guess you planned to transcode it into mp3 or ogg. so it will do.

there are two options i would personnaly recommend :
1. fix both streams with BeSplit.
2 (option a). add single-frame delay to the second stream and join the first stream with the new second stream.
2 (option b). use BeSlice to create a single frame from the second stream and join the three streams (first,single,second).
3. transcode.