На чтение 11 мин Обновлено 15.01.2023
Video not opening on Aegisub, how to convert to regular format?
Thread Tools
Display
I want to try subbing anime, but the only raws I found are fmp4 or ogm format, and it won’t open. I get this http://prntscr.com/n9kpg9 message. I tried ogm to avi converter, didn’t work at all. How do I convert the file to normal format that Aegisub recognizes and opens?
As you can read, Aegisub tries different attempts, but all fail: Even both an internal FFmpeg reader and DirectShow. So I wonder if you are dealing with a corrupt file.
Can you play it in any media player? Can you show us a MediaInfo header analysis? (MPC-HC contains one in its info dialog, Shift+F10)
Yes, it works perfectly on MPC and VLC players.
Here’s the short ver of Shift + F10 in video itself: Video: FMP4 640×480 29.97fps [V: mpeg4 simple profile, yuv420p, 640×480]
Audio: MP3 48000Hz stereo 128kbps [A: Japanese [Japanese[jpn]] (mp3, 48000 Hz, stereo, 128 kb/s)]
Audio: MP3 48000Hz stereo 128kbps [A: English [English[eng]] (mp3, 48000 Hz, stereo, 128 kb/s)]
And the long info when right-clicking on file and accessing MediaInfo:
General
Complete name : C:UsersadminDownloads1 — Indigo League47 — Lucky no karute (Jap+Eng).ogm
Format : Ogg
File size : 178 MiB
Duration : 19 min 30 s
Overall bit rate : 1 275 kb/s
Video
ID : 0 (0x0)
Format : MPEG-4 Visual
Format profile : Simple@L1
Format settings, BVOP : No
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : FMP4
Duration : 19 min 30 s
Bit rate : 958 kb/s
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 (29970/1000) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.104
Stream size : 134 MiB (75%)
Writing library : FFmpeg0.4.9-pre1b4747
Audio #1
ID : 1 (0x1)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Format settings : Joint stereo / MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 19 min 30 s
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Stream size : 17.9 MiB (10%)
Writing library : libVorbis 1.0 (UTC 2002-07-17)
Language : Japanese
Audio #2
ID : 2 (0x2)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Format settings : Joint stereo / MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 19 min 30 s
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Stream size : 17.9 MiB (10%)
Writing library : libVorbis 1.0 (UTC 2002-07-17)
Language : English
Источник
Aegisub Parsing Error When Importing SRT
I am trying to load an SRT into Aegisub, but every time I try I get an error saying «expected timestamp pair at line 2». I have checked the SRT thoroughly, and there are no errors with syntax or anything, and there is clearly a timestamp pair at line 2. The subtitles play perfectly in VLC media player.
Has anyone experienced this? It is driving me nuts.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
Jean Dimitriadis 
This person is a ProZ.com Certified PRO in английский => французский
Click the red seal for more information on what it means to be a ProZ.com Certified PRO. ‘, this, event, ‘300px’)» onMouseout=»delayhidetip()»> Член ProZ.com
английский => французский
+ .
| Troubleshooting | Oct 4, 2017 |
Hello,
This seems to be an error thrown by Aegisub during its initial parsing of an SRT file.
Maybe this article can help you spot/fix the possible error? The devil is in the details.
You can also paste the first lines of the SRT here.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
Here are the first three lines:
1
00:00:00,000 —> 00:00:04,000
The text is written here.
I know it is reading the index numbers because when I delete the 1 that error comes up. For some reason it does not like my time stamps.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
I tried putting the text on a different PC and saving that file as an SRT and it works now.
Thanks for the help.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
Jean Dimitriadis
This person is a ProZ.com Certified PRO in английский => французский
Click the red seal for more information on what it means to be a ProZ.com Certified PRO. ‘, this, event, ‘300px’)» onMouseout=»delayhidetip()»> Член ProZ.com
английский => французский
+ .
Hello Robert,
I’m glad you’ve fixed it.
I can’t see any error in the timestamp you provided.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
Jean Dimitriadis wrote:
This seems to be an error thrown by Aegisub during its initial parsing of an SRT file.
Maybe this article can help you spot/fix the possible error? The devil is in the details.
You can also paste the first lines of the SRT here.
I came here via Google because I had this very problem. The article you linked to suggested that Aegisub and some other subtitle editors would fix parsing errors automatically. This was a bit of a Catch 22 as the parsing error was preventing Aegisub from loading the file!
However, I downloaded another program, Subtitle Edit, which could open my file, I then saved it and Bingo!, Aegisub could now open the newly-saved file.
I have since worked on the text of the file in Notepad and had it fail to load in the video player (VLC) several times, but each time loading and saving in Subtitle Edit fixed the problem.
[Edited at 2017-12-19 07:11 GMT]
[Edited at 2017-12-19 07:12 GMT]
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
I came to this topic in the same way as previous posters but couldn’t use the Subtitle Edit solution as it’s not available for Mac.
However, I ultimately solved the issue by working out that it had something to do with how the line breaks were formatted. I opened my broken srt file in textedit and used the find and replace function to search for line breaks. I then simply replaced them with line breaks. I don’t really understand how this worked, but it di . See more
I came to this topic in the same way as previous posters but couldn’t use the Subtitle Edit solution as it’s not available for Mac.
However, I ultimately solved the issue by working out that it had something to do with how the line breaks were formatted. I opened my broken srt file in textedit and used the find and replace function to search for line breaks. I then simply replaced them with line breaks. I don’t really understand how this worked, but it did!
Источник
Aegisub Parsing Error When Importing SRT
I am trying to load an SRT into Aegisub, but every time I try I get an error saying «expected timestamp pair at line 2». I have checked the SRT thoroughly, and there are no errors with syntax or anything, and there is clearly a timestamp pair at line 2. The subtitles play perfectly in VLC media player.
Has anyone experienced this? It is driving me nuts.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
Jean Dimitriadis
This person is a ProZ.com Certified PRO in английский => французский
Click the red seal for more information on what it means to be a ProZ.com Certified PRO. ‘, this, event, ‘300px’)» onMouseout=»delayhidetip()»> Член ProZ.com
английский => французский
+ .
| Troubleshooting | Oct 4, 2017 |
Hello,
This seems to be an error thrown by Aegisub during its initial parsing of an SRT file.
Maybe this article can help you spot/fix the possible error? The devil is in the details.
You can also paste the first lines of the SRT here.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
Here are the first three lines:
1
00:00:00,000 —> 00:00:04,000
The text is written here.
I know it is reading the index numbers because when I delete the 1 that error comes up. For some reason it does not like my time stamps.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
I tried putting the text on a different PC and saving that file as an SRT and it works now.
Thanks for the help.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
Jean Dimitriadis
This person is a ProZ.com Certified PRO in английский => французский
Click the red seal for more information on what it means to be a ProZ.com Certified PRO. ‘, this, event, ‘300px’)» onMouseout=»delayhidetip()»> Член ProZ.com
английский => французский
+ .
Hello Robert,
I’m glad you’ve fixed it.
I can’t see any error in the timestamp you provided.
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
Jean Dimitriadis wrote:
This seems to be an error thrown by Aegisub during its initial parsing of an SRT file.
Maybe this article can help you spot/fix the possible error? The devil is in the details.
You can also paste the first lines of the SRT here.
I came here via Google because I had this very problem. The article you linked to suggested that Aegisub and some other subtitle editors would fix parsing errors automatically. This was a bit of a Catch 22 as the parsing error was preventing Aegisub from loading the file!
However, I downloaded another program, Subtitle Edit, which could open my file, I then saved it and Bingo!, Aegisub could now open the newly-saved file.
I have since worked on the text of the file in Notepad and had it fail to load in the video player (VLC) several times, but each time loading and saving in Subtitle Edit fixed the problem.
[Edited at 2017-12-19 07:11 GMT]
[Edited at 2017-12-19 07:12 GMT]
| Subject: | |
| Comment: | The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional) |
I came to this topic in the same way as previous posters but couldn’t use the Subtitle Edit solution as it’s not available for Mac.
However, I ultimately solved the issue by working out that it had something to do with how the line breaks were formatted. I opened my broken srt file in textedit and used the find and replace function to search for line breaks. I then simply replaced them with line breaks. I don’t really understand how this worked, but it di . See more
I came to this topic in the same way as previous posters but couldn’t use the Subtitle Edit solution as it’s not available for Mac.
However, I ultimately solved the issue by working out that it had something to do with how the line breaks were formatted. I opened my broken srt file in textedit and used the find and replace function to search for line breaks. I then simply replaced them with line breaks. I don’t really understand how this worked, but it did!
Источник
Adblock
detector
-
-
October 25 2009, 09:57
Здравствуйте!
Обращаюсь к (теперь) третей с конца записи (Программные обеспечиея для субтитрования). Я тоже вхожу в состав группы университета в Лечче и я тоже занимаюсь пректом связаным с субтитрованием. Задача наша – добавить субтитры (на итальянском, они – перевод русского видео) к одному видео. Т.е. у нас нет уже подготовленного файла с субтитрами, поэтому было бы лучше, если бы мы могли работать вместе с видео, чтобы ключать субтитрты в подхадяшее время. Не знаю, правильно ли меня поняли…
Дело в том, что я скачала программу Aegisub, но мне не позволяет добавить видео, или, если мне удается это сделать, с другой стороны не могу играть видео. Появляется следующее сообщение (по-английски): «Oops! Aegisub has crashed!»
Читала руководство и (кстати) там написанно, что Agisub не предусмотривает играть видео, или если она играет видео, то это может вызвать несколько проблем…как и мне произошло.
Я также скачала VisualSubSync и мне кажется, что программа лучше подходит к нашей задаче. Но, так как вы посоветовали Aegisub использовать, не подскажите ли вы как решить выше выясненную проблему?
Заранее спасибо!
|
Off topic: Aegisub: Error loading file, Parsing SRT: Expected subtitle index at line 1 Thread poster: Coen Boot |
||||||||
|---|---|---|---|---|---|---|---|---|
|
Coen Boot
|
||||||||
|
Coen Boot TOPIC STARTER
|
There is no moderator assigned specifically to this forum.
To report site rules violations or get help, please contact site staff »
Aegisub: Error loading file, Parsing SRT: Expected subtitle index at line 1
|
||
|
Hey y’all, I work with subtitling and had a technical problem today I was hoping to get some help with. I’m having trouble with loading my audio track onto Aegisub so I can create my subtitles. I’ve tried opening both video and audio files individually from the source, and get the same problem every time: the audio loads, but I can only hear/see the waveforms of background audio. No dialogues at all, which is obviously what I need to be able to see and hear to make the subs. I don’t know if it’s a problem with Aegisub or the file, but I’m guessing it’s Aegisub since the file plays normal on VLC. I’ve tried converting the vid and extracting the audio but nothing seems to work. Please send help??!! Here are the formats if that helps at all: Video is and MP4, nothing special there Audio has a Bit rate of 189kbps, two channels, and 48000 kHz sample rate.
I’m fairly used to Aegisub but only use it occasionally, since I’ve been using it to sub for awhile but have only done five or six subs over the past two years — but still, have never come across this before.
Would be much obliged if anyone could shed some light here. Thanks!!
Edit: First sentence
wangqr
added a commit
to wangqr/Aegisub
that referenced
this issue
May 19, 2019
This should make loading UTF-8-BOM files faster. This also guarentee Aegisub will load large ass saved by itself. See Aegisub#110
wangqr
added a commit
to wangqr/Aegisub
that referenced
this issue
May 19, 2019
Now feeds all data to uchardet, when uchardet is available. The file size limit is removed. When uchardet is not available, we look for UTF-8 BOM. This should make loading UTF-8-BOM files faster. Because Aegisub always save file in UTF-8-BOM, this should also guarentee Aegisub will load large (>100MB) file saved by itself. See Aegisub#110
scx
mentioned this issue
Sep 6, 2019
scx
added a commit
to scx/Aegisub
that referenced
this issue
Sep 7, 2019
Now feeds all data to uchardet, when uchardet is available. The file size limit is removed. When uchardet is not available, we look for UTF-8 BOM. This should make loading UTF-8-BOM files faster. Because Aegisub always save file in UTF-8-BOM, this should also guarentee Aegisub will load large (>100MB) file saved by itself. See Aegisub#110
scx
added a commit
to scx/Aegisub
that referenced
this issue
Sep 7, 2019
This should make loading UTF-8-BOM files faster. This also guarentee Aegisub will load large ass saved by itself. See Aegisub#110
scx
added a commit
to scx/Aegisub
that referenced
this issue
Sep 7, 2019
Now feeds all data to uchardet, when uchardet is available. The file size limit is removed. When uchardet is not available, we look for UTF-8 BOM. This should make loading UTF-8-BOM files faster. Because Aegisub always save file in UTF-8-BOM, this should also guarentee Aegisub will load large (>100MB) file saved by itself. See Aegisub#110
scx
mentioned this issue
Sep 8, 2019
milahu
pushed a commit
to milahu/AegisubDC
that referenced
this issue
Mar 2, 2022
Now feeds all data to uchardet, when uchardet is available. The file size limit is removed. When uchardet is not available, we look for UTF-8 BOM. This should make loading UTF-8-BOM files faster. Because Aegisub always save file in UTF-8-BOM, this should also guarentee Aegisub will load large (>100MB) file saved by itself. See Aegisub/Aegisub#110
Background:
Last time trying to use Aegisub was just a simple task to shift the subtitle timing for several sec. for the whole subtitle syncronization with the video clip. This time just I want to do a pilot project to publishing Chinese subtitle for a video clip from public domain.
Issue:
A video subtitle editor – Aegisub always shows error message below when selecting
Audio -> Open Audio from Video
Error loading file:
RIFF PCM WAV audio provider: File is not a RIFF file
Wave64 audio provider: File is not a Wave64 RIFF file
FFmpegSource: unknown or unsupported sample format
Solution:
Use HandBrake to convert the input video to the following output file:
Video format: MKV, MPEG-4(FFmpeg)
Audio format: FLAC (ffmpeg)
Config:
- Aegisub 3.0.4
- HandBrake 0.9.9
- OpenSuse 12.3
Tricks:
- If MP4 is chosen instead of MKV, the FLAC (ffmpeg) cannot be selected in HandBrake
- Many other Subtitle Editors for Linux are not comprehensive enough to do an easy job for making subtitles, e.g. most of them cannot display the wave form of the audio that can be used to estimate the voice timing
- In case the Audio cannot be open from Video, Aegisub cannot even play the sound track