video ripping problem

[afterburn25]

Im having a problem with videos ive ripped using web stream recorder ripping worked very well kept the hd quality and sound video played fine for the most part however there is a couple of points during video where picture slows down and you can see the lips moving but instead of the words being what the lips are saying it is repeating the sound from earlier in the video.

at first i thought it just was corrupted in the ripping process but then after it gets past that point i moved the slide bar to take me back to that point that it messed up and now it plays just fine it always messed up at exact same spot and every single time i move back to that position it plays fine.

what could be causing this i have tried using different players i get the same thing even ripped it using a different ripper and still exact same thing. video is in flash


ok an update I got a little more info on this issue I used a different player and when it gets to the point that messes up its not repeating sound on this one it jumps back the first time i tried i played from the beginning after 1:08 it jumped back like 40 seconds but then after i played it close to the spot that messed up it still jumps back at 1:08 but it only jumps back to 1:01 then if you let it play through it will play past that point.

[aazerty]

Hi afterburn25 ,

I am no a specialist !!! Maybe this will help .
Example given for a file named 'RaiStoria.ts' .
_ first look inside to know what kind of streams are existing .
_ if many streams exist try to melt them .

ffmpeg -i RaiStoria.ts

ffmpeg version N-53284-gd0a34ae Copyright (c) 2000-2013 the FFmpeg developers
...
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'RaiStoria.ts':
  Metadata:
    major_brand     : isom
    minor_version   : 1
    compatible_brands: isom
    creation_time   : 2015-01-04 23:45:37
  Duration: 00:00:26.25, start: 0.000000, bitrate: 1007 kb/s
    Stream #0:0(und): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 480x272 [SAR 136:135 DAR 16:9], 991 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
    Metadata:
      creation_time   : 2015-01-04 23:45:37
    Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 32000 Hz, stereo, fltp, 62 kb/s
    Metadata:
      creation_time   : 2015-01-04 23:45:37

For getting a new file (With the previous example) you could write 
ffmpeg -i RaiStoria.ts -c copy -f mp4 RaiStoria.mp4
( egal to ffmpeg -i RaiStoria.ts -c copy -map 0:0 -map 0:1 -f mp4 RaiStoria.mp4 )

You could see while the process
---
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (copy)
---

Now supposing you have many streams , search for quality ( video and audio )

ffmpeg -i RaiStoria.ts -c copy -map 0:6 -map 0:7 -f mp4 RaiStoria.mp4

---
Stream mapping:
Stream #0:6 -> #0:0 (copy) <= for video
Stream #0:7 -> #0:1 (copy) <= for audio
---

Regards .

[afterburn25]

omg lol I wouldn't even know where to begin doing all that

[Cornucopia]

Start by learning what the difference between ripping and stream recording/capturing is.

Scott

[afterburn25]

umm it is ripping the so called streams are prerecorded so there is a file that is downloaded

[Cornucopia]

No need for an "umm", that's just not ripping.

Ripping is strictly the extraction of assets from an authored media disc (e.g. AudioCD, VCD, DVD, HD-DVD, Blu-ray, SACD) - with optional decryption - and copying the result onto HDD, etc.

File downloading is just file copying using network protocols (http:, ftp:, etc.) of files on one networked device to another (in the case of client->server it is uploading, in the case of server->client it is downloading).

Stream recording/capturing is the reception of incoming streams of data and routing them to permanent storage (sometimes even when the pervailing method doesn't expect more than transitory storage). Both RTSP/MMS/etc. and Firewire-DV are forms of stream recording.

Scott

[afterburn25]

i was only looking for help on this issue and i know the definition of ripping i was ripping cd's since the mid 90's i only wanted help on this issue not flame posts if you don't have anything useful to contribute then you shouldn't be posting and certainly have no business trolling.

[manono]

You just joined and you're trying to take on one of our oldest and most respected members? I'll assume English is your first language. Please correct me if I'm wrong. If you want to be taken seriously you should at least make an attempt not to write and sound like a semi-literate moron.

[Cornucopia]

Don't sweat it, manono. I'm not. Got a chuckle out of it (particularly the part about ripping CDs - I've been doing it since '88-'89 - but at least he got the term correct that time).

@afterburn25, after you remove your foot from your mouth, here are a couple of things to think about...

#1 - I wouldn't be so sure you got a clean, un-corrupted capture (not "rip"). Try re-recording a couple of times, with different apps, and do a bitwise compare. If they aren't corrupt, they should be identical. If they are, that is the first thing to fix...
#2 - Problems with timing (that aren't determined to be cause by a corrupted capture) usually have to do with bad/incomplete headers and/or indexing, or with the existence of VFR.
#3 - You can find out if it's VFR by looking at the tags in MediaInfo. If it is, I strongly suggest you convert it to CFR first (other threads give info on how to do that).
#4 - You can use Vdub to fix some/most of the headers, and re-wrapping it in a new container should re-index it. There is also DivFix++ and other index repair tools available.
#5 - aazerty might have been on the right path with the idea of removing extraneous streams (which ought to re-wrap, and probably re-index the file anyway).

Scott

[afterburn25]

Don't sweat it, manono. I'm not. Got a chuckle out of it (particularly the part about ripping CDs - I've been doing it since '88-'89 - but at least he got the term correct that time).

@afterburn25, after you remove your foot from your mouth, here are a couple of things to think about...

#1 - I wouldn't be so sure you got a clean, un-corrupted capture (not "rip"). Try re-recording a couple of times, with different apps, and do a bitwise compare. If they aren't corrupt, they should be identical. If they are, that is the first thing to fix...
#2 - Problems with timing (that aren't determined to be cause by a corrupted capture) usually have to do with bad/incomplete headers and/or indexing, or with the existence of VFR.
#3 - You can find out if it's VFR by looking at the tags in MediaInfo. If it is, I strongly suggest you convert it to CFR first (other threads give info on how to do that).
#4 - You can use Vdub to fix some/most of the headers, and re-wrapping it in a new container should re-index it. There is also DivFix++ and other index repair tools available.
#5 - aazerty might have been on the right path with the idea of removing extraneous streams (which ought to re-wrap, and probably re-index the file anyway).

Scott

Well thank you for the information I used Web stream recorder to capture I tried a lot of others that really didn't work took a while to find this program are there any other programs that do work? I don't mind paying for a program as long as it works.

[aazerty]

Hi afterburn25 ,

Have you tried at least for one video , what i said : ffmpeg -i "video" .
If yes what is the result ?

Cheers .