[SOLVED] What is xdelta3?

[professa X]

checkum has piqued my interest in it. Like why do that? I've been just taking video and audio and synching together. Why does vivid have this xdelta3 thing?

Edited June 6, 2015 by professa X

[JohnFlower]

People use it because it saves downloading an entirely new file. Say you wanted to edit a line in your subtitle track or add a new audio track. xdelta will allow you to compare the two binary files (in this case, mkv files) and create a diff. The diff file will only contain data that is different between the two files.

It has nothing to do with video and audio syncing unless you are patching to fix that.

Vivid use it to patch their files.

[professa X]

People use it because it saves downloading an entirely new file. Say you wanted to edit a line in your subtitle track or add a new audio track. xdelta will allow you to compare the two binary files (in this case, mkv files) and create a diff. The diff file will only contain data that is different between the two files.

It has nothing to do with video and audio syncing unless you are patching to fix that.

Vivid use it to patch their files.

 

So what i see is that vivid releases subbed hdtv (example). Now i need the english audio to be synched along with it. Ok now this is where i'm getting lost. How is checkum's xdelta files helping in adding english audio? Are those files acual audio files or are they supposed to be used along with some other english audio file? Essentially what I am asking is why would chekem do that if all one had to do is get the presynced audio (.mp4 etc) and mux with the vivid release. How is checkem actually helping by providing these xdelta files.

 

Thanx

[JohnFlower]

In effect, checkem's files are the audio. They will have the extra Matroska data (audio delay, header etc.) and the audio data, so you cant play them in your favourite audio player.

Essentially what you're doing is adding checkem's files to Vivid's release. For this case: download Vivid's sub only release and checkem's delta files, then run xdelta. This will create another file with Vivid's release and checkem's audio.

[professa X]

In effect, checkem's files are the audio. They will have the extra Matroska data (audio delay, header etc.) and the audio data, so you cant play them in your favourite audio player.Essentially what you're doing is adding checkem's files to Vivid's release. For this case: download Vivid's sub only release and checkem's delta files, then run xdelta. This will create another file with Vivid's release and checkem's audio.

Interesting. I see what it accomplishes. So i presume vivid releases require this xdelta method?

Another question; why not mkvmerge video with audio that has been synched (with audacity). Why would they op for xdelta when they could do like everyone else and. Provide the video file and someone else provide the audio file that was synced via audacity editing.

 

Edit: 

 

Here is what i gathered so far. after muxing every one can potentially have a different file. The one painstakingly synced the audio will have a different time counter than a person who would do the exact syncing for the exact video on there own computer. So if i made some synced audio for distribution, not the synced video, anyone who tries to mux it with the intended video can have varying results per person. But with Xdelta this is not the case so therefore safer. 

 

If I am correct then this is actually pretty cool. 

Edited June 5, 2015 by professa X

[RedStrat]

 

Interesting. I see what it accomplishes. So i presume vivid releases require this xdelta method?

 

Why would vivd releases require xdelta? This has nothing to do with their subbed releases. You can download their subbed stuff and watch it as is.

The xdelta part is only if you want to add english audio, so no it's not "required".

 

 

 

Another question; why not mkvmerge video with audio that has been synched (with audacity). Why would they op for xdelta when they could do like everyone else and. Provide the video file and someone else provide the audio file that was synced via audacity editing.

 

But audacity and mkvmerge are what he used to edit and mux the audio into vivid's release. Then he just uses xdelta to create a patch so other people don't have to actually do that. They just run a file/command.

 

 

Edit: 

 

Here is what i gathered so far. after muxing every one can potentially have a different file. 

 

It's not potentially. If you and someone else mux the exact same thing you will get a different file. You can try muxing the exact same thing twice and check the CRC if you want. The two actual files will be different, even if in essence it's the same video, same audio, same subs, same sync.

 

 

 

 The one painstakingly synced the audio will have a different time counter than a person who would do the exact syncing for the exact video on there own computer. So if i made some synced audio for distribution, not the synced video, anyone who tries to mux it with the intended video can have varying results per person. But with Xdelta this is not the case so therefore safer. 

If I am correct then this is actually pretty cool. 

 

 

No. If you release your synced audio and other people mux it in the intended video, they will have a different file... But nothing to do with bad sync. Their audio will be just as synced as yours. So no "varying results per person". But the file is still different.

 

So theoretically releasing just the audio would be fine just for watching. But...

• It requires that people actually get mkvtoolnix (that's a scary name) and use it to mux (that's a scary word) the synced audio. People don't want that.

• As I said, your files will be different... So if we're talking about torrents you won't be able to seed. Even if you put exactly the same audio in the same video. No seeding.

 

That's why when fansubs make a v2 of some episode they often release a xdelta patch. So you can create the exact v2 file from the v1 if you already have it.

So for example if you have downloaded the, say, 350MB v1 file and then the team releases a v2 that has better sub translation/timing or whatever, you don't have to download again 350MB. You only download the patch which will be way smaller than the whole file. If it's just a subtitle fix it will only be a few kB. You apply it to the v1 file and create exactly the same v2 file that they have, so you are able to seed their new torrent.

Edited June 5, 2015 by BlackStrat

[professa X]

 

 

Interesting. I see what it accomplishes. So i presume vivid releases require this xdelta method?

 

Why would vivd releases require xdelta? This has nothing to do with their subbed releases. You can download their subbed stuff and watch it as is.

The xdelta part is only if you want to add english audio, so no it's not "required".

 

 

 

Another question; why not mkvmerge video with audio that has been synched (with audacity). Why would they op for xdelta when they could do like everyone else and. Provide the video file and someone else provide the audio file that was synced via audacity editing.

 

But audacity and mkvmerge are what he used to edit and mux the audio into vivid's release. Then he just uses xdelta to create a patch so other people don't have to actually do that. They just run a file/command.

 

 

Edit: 

 

Here is what i gathered so far. after muxing every one can potentially have a different file. 

 

It's not potentially. If you and someone else mux the exact same thing you will get a different file. You can try muxing the exact same thing twice and check the CRC if you want. The two actual files will be different, even if in essence it's the same video, same audio, same subs, same sync.

 

 

 

 The one painstakingly synced the audio will have a different time counter than a person who would do the exact syncing for the exact video on there own computer. So if i made some synced audio for distribution, not the synced video, anyone who tries to mux it with the intended video can have varying results per person. But with Xdelta this is not the case so therefore safer. 

If I am correct then this is actually pretty cool. 

 

 

No. If you release your synced audio and other people mux it in the intended video, they will have a different file... But nothing to do with bad sync. Their audio will be just as synced as yours. So no "varying results per person". But the file is still different.

 

So theoretically releasing just the audio would be fine just for watching. But...

• It requires that people actually get mkvtoolnix (that's a scary name) and use it to mux (that's a scary word) the synced audio. People don't want that.

• As I said, your files will be different... So if we're talking about torrents you won't be able to seed. Even if you put exactly the same audio in the same video. No seeding.

 

That's why when fansubs make a v2 of some episode they often release a xdelta patch. So you can create the exact v2 file from the v1 if you already have it.

So for example if you have downloaded the, say, 350MB v1 file and then the team releases a v2 that has better sub translation/timing or whatever, you don't have to download again 350MB. You only download the patch which will be way smaller than the whole file. If it's just a subtitle fix it will only be a few kB. You apply it to the v1 file and create exactly the same v2 file that they have, so you are able to seed their new torrent.

 

BAMF. Than you for the break down. You were sharp but straight to the point. MAD Props. add me as a friend?

[d2x]

i feel like i should chime in since this thread partly concerns my releases.

 

i use xdelta patches over providing audio files because the patches provide more than just audio; they also provide a signs/songs-only subtitle track since those parts still require a translation. they also prevent people from being silly and muxing the audio with other releases since it's not synced to them.

 

i do not use audacity for cutting lossy audio. i avoid transcoding audio in my workflow unless i need to splice in audio from another source and it uses a different codec/sample rate/etc.

[RedStrat]

 

i do not use audacity for cutting lossy audio. i avoid transcoding audio in my workflow unless i need to splice in audio from another source and it uses a different codec/sample rate/etc.

 

Yeah I did not know about your releases nor what show he was talking about so I had no idea what kind of audio you were working with.

Obviously since it seems Audacity can't export your work without re-encoding even if all you did was add/remove just a wee bit of silence, it shouldn't be used with lossy codecs. Well maybe it can but I couldn't find a way when I was looking for it a while back.

Edited June 7, 2015 by BlackStrat

[JohnFlower]

Why are you using lossy audio as your source?

[d2x]

Why are you using lossy audio as your source?

funi broadcast dub sources don't provide lossless audio

[JohnFlower]

Which is why you shouldn't use them. The only valid reason to use a lossy audio source is when it's only available from a DVD. Any other case is invalid.

Of course this reasoning only applies to people creating archive worthy releases. If you want TV audio/web audio on your Coalgirls release, then go ahead. Just don't expect sane people to like it.

[Koby]

Which is why you shouldn't use them. The only valid reason to use a lossy audio source is when it's only available from a DVD. Any other case is invalid.

Of course this reasoning only applies to people creating archive worthy releases. If you want TV audio/web audio on your Coalgirls release, then go ahead. Just don't expect sane people to like it.

It's for people who want to watch the Simulcast Dubs. Obviously people aren't going to archive dual-audio Japanese HDTV video with Webstreamed audio. The archive worthy releases come later with the BDs.

[JohnFlower]

If you're not archiving, then you can be lazy and edit with your favourite editor. There's no point being pedantic about a watch and delete release...