AnimeSuki Forums

Register Forum Rules FAQ Members List Social Groups Search Today's Posts Mark Forums Read

Go Back   AnimeSuki Forum > Anime Related Topics > General Anime > Fansub Groups

Notices

Reply
 
Thread Tools
Old 2006-01-15, 18:32   Link #241
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
Quote:
Originally Posted by Quarkboy
Actually, though, it's probably better for them to use the xml type format, as it's far easier to parse than ssa (which I've been told is notoriously annoying to parse). It'll be easier for people to write software that manipulates it.
It's also much more difficult to try to edit it in a normal text editor. XML might be easy to parse, but it's incredibly annoying for humans to write subtitles in. Consider the following (from one of the USF samples):
Code:
<subtitle start="00:00:26.000" stop="00:00:30.000">
      <text>Size : <font size="14">14</font>-<font size="16">16</font>-<font size="20">20</font>-<font size="26">26</font>-<font size="40">40</font>...</text>
</subtitle>

<subtitle start="00:00:58.000" stop="00:01:01.000">
      <karaoke style="MusicLyrics"><k t="500"/><font color="#00AAFF">Multi-colors</font><k t="500"/> and <k t="500"/><font color="#00FFAA">Multi-lines</font><br/><k t="1500"/>Karaokeeeee!!!</karaoke>
</subtitle>
Feel like shuddering yet? I certainly do. Some annoyance at the programmers part once is probably prefereable to the annoyance of every typesetter in existence every time they use the format... Now, I'm not saying SSA is perfect, because it's certainly not (it has HUGE amounts of annoying quirks, some of them caused by the ancient evil VSFilter), but the syntax is certainly better than XML, at least for humans.
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read

Last edited by TheFluff; 2006-01-15 at 18:51.
TheFluff is offline   Reply With Quote
Old 2006-01-15, 18:41   Link #242
ArchMageZeratuL
Aegisub dev
*IT Support
 
 
Join Date: Dec 2004
Location: Florianópolis, Brazil, Pale Blue Dot
Age: 29
Well, with the notorious exception of override tags, ASS/SSA are very easy to parse... I believe that XML just DOESN'T WORK for subtitles. This might be related to my reluctance to write an USF parser/writer into Aegisub.
__________________
Aegisub developer [ Forum | Wiki | Bugtracker | IRC ]
ArchMageZeratuL is offline   Reply With Quote
Old 2006-01-15, 19:59   Link #243
Soluzar
Senior Member
 
 
Join Date: Dec 2005
Location: Derby, UK.
Age: 39
Send a message via AIM to Soluzar Send a message via MSN to Soluzar Send a message via Yahoo to Soluzar
Quote:
Originally Posted by Quarkboy
Yeah, but SSA doesn't have a "BLINK" environment.... Did I mention 3gpp has a "BLINK" environment? HASN'T ANYONE LEARNED ANYTHING?! There's a reason blink was banned from the web... and I can just imaging the abuses for subtitle streams........ the horror!
Enlighten me. What's the reason that it was banned from the web?
__________________
Richard Taylor

The Crumbling Biscuit.
Soluzar is offline   Reply With Quote
Old 2006-01-15, 20:26   Link #244
zalas
tsubasa o sagashite
 
Join Date: Jul 2003
Send a message via ICQ to zalas
Quote:
Originally Posted by ArchMageZeratuL
Well, with the notorious exception of override tags, ASS/SSA are very easy to parse... I believe that XML just DOESN'T WORK for subtitles. This might be related to my reluctance to write an USF parser/writer into Aegisub.
I think XML works for subtitles pretty well, since you can have a lot more control over how the overrides interact with each other. It's the "human-editable" part that is the problem. However, I wouldn't see a problem with a rich-text-ish GUI editor editing XML subs. At least having the "text" portion being in XML instead of including the timecodes as well in XML would be interesting, since that has built in restrictions for keeping all the text nodes in one line, which would make parsing a bit easier (don't have to worry about how line breaks are handled).
zalas is offline   Reply With Quote
Old 2006-01-16, 02:25   Link #245
Sylf
翻訳家わなびぃ
*Fansubber
 
 
Join Date: Nov 2003
Age: 40
Send a message via MSN to Sylf Send a message via Yahoo to Sylf
Subs in XML - isn't that what USF is all about?
Sylf is offline   Reply With Quote
Old 2006-01-16, 04:07   Link #246
Zero1
Two bit encoder
*Fansubber
 
 
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 30
Well fortunately you can just write your main script as SRT and have MP4box convert it. Basic formatting and font setting isn't too hard, but I suppose karaoke would be a bitch (If there was a player/parser that dealt with it correctly now). The only thing I've had an issue with so far in my limited time with TTXT is text positioning.

Again it boils down to lack of tools and general interest why TTXT is a bit of a mystery. Something like a basic SSA/ASS > TTXT conversion would be good if it would transpose such things as basic text positioning, text formatting, fonts etc. I doubt translating SSA/ASS karaoke would be of interest or even work, so I think that's a non issue right now.

The main thing is getting to grips with TTXT.

This is my TTXT script I used in my MP4 feature test. It displays nicely in GPAC's Osmo4 player, but is slightly off when using MPC's MP4 splitter. I would be inclined to trust GPAC's player more (nothing detrimental to Gabest), but since more people use MPC than Osmo4, I guess whether it looks right in MPC is more important. One thing to note, though I doubt it has much bearing, is that the video is anamorphic, and uses a SAR.

Code:
<?xml version="1.0" encoding="UTF-8" ?>
<!-- GPAC 3GPP Text Stream -->
<TextStream version="1.0">
<TextStreamHeader width="800" height="40" layer="0" translation_x="0" translation_y="390">
<TextSampleDescription horizontalJustification="center" verticalJustification="center" backColor="00 00 00 00" verticalText="no" fillTextRegion="no" continuousKaraoke="no" scroll="None">
<FontTable>
<FontTableEntry fontName="Sans-Serif" fontID="1"/>
</FontTable>
<TextBox top="0" left="0" bottom="0" right="0"/>
<Style styles="Italic" fontSize="24" color="EB EB EB FF"/>
</TextSampleDescription>
</TextStreamHeader>
<TextSample sampleTime="00:00:00.000" text="">
</TextSample>
<TextSample sampleTime="00:00:12.095" text="'Chan? I feel you.'">
</TextSample>
<TextSample sampleTime="00:00:13.347" text="">
</TextSample>
<TextSample sampleTime="00:00:14.556" text="'He&apos;s coming?'">
</TextSample>
<TextSample sampleTime="00:00:15.432" text="">
</TextSample>
<TextSample sampleTime="00:00:18.894" text="'Amuro...'">
</TextSample>
<TextSample sampleTime="00:00:19.561" text="">
</TextSample>
<TextSample sampleTime="00:00:29.196" text="'You must remember the pain you suffered when Lalah was struck down!'">
</TextSample>
<TextSample sampleTime="00:00:32.616" text="">
</TextSample>
<TextSample sampleTime="00:00:48.298" text="'You&apos;re pathetic!'">
</TextSample>
<TextSample sampleTime="00:00:49.383" text="">
</TextSample>
<TextSample sampleTime="00:00:49.716" text="'Me?!'">
</TextSample>
<TextSample sampleTime="00:00:50.300" text="">
</TextSample>
<TextSample sampleTime="00:00:52.553" text="'Why won&apos;t you realize you&apos;re the one wasting your precious talents?!'">
</TextSample>
<TextSample sampleTime="00:00:56.348" text="">
</TextSample>
<TextSample sampleTime="00:00:58.892" text="'Same with you!'">
</TextSample>
<TextSample sampleTime="00:00:59.685" text="">
</TextSample>
</TextStream>
And here's how it looks in Osmo4 (Remember Osmo4 didn't have CQM support when I took this screen)


Now using Haali's splitter (lol)


And finally the internal MPC splitter.


Oh, and as for blinking text. It's just damn annoying.
Zero1 is offline   Reply With Quote
Old 2006-01-16, 04:09   Link #247
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 35
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Soluzar
Enlighten me. What's the reason that it was banned from the web?
http://en.wikipedia.org/wiki/Blink_tag

I figured there'd be a wikipedia article on it, and I was right.

When I say "banned" I was being a bit overly emphatic. Suffice it to say that if your webpage has a lot of "blink" tags, most people consider that in terrible taste.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2006-01-16, 19:33   Link #248
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 35
Send a message via AIM to Quarkboy
For interested people, I used the -nr parameter in my latest release of Sugar sugar Rune 03.
It might be a good idea for someone to compare with episode 2 (which did not use it).

From my experience so far, with a strength of 100-200 there's very little visible difference, but a bitrate savings of up to 2% on a DVD-raw based anime source. For a really noisy source, it had much greater savings, nearly 10%... however it didn't really denoise well, so what would probably happen would be a series of filters before the encode that would already kill most of that noise anyway.

In any case, as far as I can tell it looks like free bits to me, so there's no reason not to use it at low levels on all encodes (it doesn't seem to slow down encoding much at all).
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2006-01-23, 11:10   Link #249
Sylf
翻訳家わなびぃ
*Fansubber
 
 
Join Date: Nov 2003
Age: 40
Send a message via MSN to Sylf Send a message via Yahoo to Sylf
It sounds like CoreAVC won't stay free. Sources 1, 2

TCPMP/CoreAVC combo gave the absolutely lowest system requirements for AVC playback that I've seen, so I was hoping that they'd make a good, viable, free solution to those people with limited resources and want things for free. Afterall, if you don't have money to upgrade your PC, why would you pay for some software just to watch fansubs? If you have money to upgrade, then you can use ffdshow just fine. And also buy R1 DVDs too.
Sylf is offline   Reply With Quote
Old 2006-01-23, 11:38   Link #250
outlaw97
Senior Member
 
Join Date: Mar 2004
I'd pay for it just for the chance to be able to view h264 on my Dell Axim x51v PDA.


One of the reasons I bought it was for the convenience of watching a couple eps when I have downtime on the road - I was able to do this thanks to their program, TCPMP.

Just my luck that a month after I buy it people start shifting to H264 releases, which causes my pda to choke. I am hoping that they can optimize coreavc more once they go to a paid model.
outlaw97 is offline   Reply With Quote
Old 2006-01-23, 13:31   Link #251
Eeknay
Gendo died for your sins.
*Fansubber
 
 
Join Date: Dec 2005
Yeah, they mentioned it a few times in the initial CoreAVC thread that it wouldn't remain free... shame, it's a great decoder for slower CPUs.

Hope you got a copy before they removed the link.
Eeknay is offline   Reply With Quote
Old 2006-02-02, 09:54   Link #252
CompShrink
getting in comps' heads
 
Join Date: Jan 2003
Location: #ToTan @ irc.chatsociety.net
Send a message via AIM to CompShrink
Quote:
Originally Posted by outlaw97
I'd pay for it just for the chance to be able to view h264 on my Dell Axim x51v PDA.


One of the reasons I bought it was for the convenience of watching a couple eps when I have downtime on the road - I was able to do this thanks to their program, TCPMP.

Just my luck that a month after I buy it people start shifting to H264 releases, which causes my pda to choke. I am hoping that they can optimize coreavc more once they go to a paid model.
I just do a quick 1 pass reencode to divx in virtualdub and play it back with PocketMPV on my Axim X5.
You can simply do an AVS script of one line:
DirectShowSource("Filename.mkv")

and open the file with virtualdub to be able to encode h264 -> divx, assuming you can play back h264 on your comp and have a divx/xvid encoder installed too.

Yeah, old model, but still has a 400mhz proc and 64mb ram, plays back video at perfectly decent quality imho.

Yeah, h264 would be better quality, but considering many low end desktops have trouble with it, playback on a pda seems a little out of reach.
CompShrink is offline   Reply With Quote
Old 2006-02-05, 06:46   Link #253
Trejkaz
Junior Member
 
Join Date: Feb 2006
I thought PDAs and other portable media devices (e.g. PSP) were the main reason for using H.264 in the first place since hardware acceleration solves some of those performance problems.

On the desktop, the codec changes so often that a video encoded with today's version won't work on one from a week ago. I mean, I don't fear change. Hell, I upgrade all the software on my Linux desktop about once a month. But change more than once a month just to keep up with the changing face of a single format is a bit much to bear.

And those of us who were previously using an Xbox to watch our anime are now stuck between a rock and a hard place. Playback even in cutting edge versions of XBMC is too choppy to be enjoyable, and the only road out is upgrading to a faster or different video playing device. Oh yes, and don't forget that only an extremely tiny number of digital video players can even play H.264 in the first place.

What I think would float, and what would satisfy most people... is a site which takes all the H.264 encodes and transcodes them to XviD. Then you have the best of both worlds. Fansubbers who like H.264 don't have to listen to complaints about it and can happily sub only in H.264. And fans who don't like H.264 wouldn't then have to deal with it. Or at least we'd have something to do in the interim until the codecs get more stable.
Trejkaz is offline   Reply With Quote
Old 2006-02-05, 07:04   Link #254
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 35
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Trejkaz
I thought PDAs and other portable media devices (e.g. PSP) were the main reason for using H.264 in the first place since hardware acceleration solves some of those performance problems.

On the desktop, the codec changes so often that a video encoded with today's version won't work on one from a week ago. I mean, I don't fear change. Hell, I upgrade all the software on my Linux desktop about once a month. But change more than once a month just to keep up with the changing face of a single format is a bit much to bear.
That's really not true at all. An encode made by pretty much any version of x264 (except a few borked ones ) since revision 200 or so (it's now on 400), like, back in August... will play fine with the latest ffdshow. It's true that newer versions of x264 have added options that old ones didn't, but that's a decoding issue and newer decoders should have no problems playing older encodes that don't have some of the latest features (like custom quant matrices, etc).

Since custum quants were added back in August or so, all improvements to x264 have been in the encoding algorithm itself, i.e. require no change in the decoders. Options like --nr or --no_fast_pskip or --bime --mixed refs... those are all options that modify how the encoder encodes the video, but do not require any further functionality on the part of the decoder.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2006-02-05, 07:25   Link #255
Trejkaz
Junior Member
 
Join Date: Feb 2006
Quote:
Originally Posted by Quarkboy
That's really not true at all. An encode made by pretty much any version of x264 (except a few borked ones ) since revision 200 or so (it's now on 400), like, back in August... will play fine with the latest ffdshow. It's true that newer versions of x264 have added options that old ones didn't, but that's a decoding issue and newer decoders should have no problems playing older encodes that don't have some of the latest features (like custom quant matrices, etc).
So you're saying what I said isn't true, but then saying it is true.

I said: "the codec changes so often that a video encoded with today's version won't work on one from a week ago."

These new options are exactly what cause the problem. As soon as someone encodes a video using a new feature of the codec, the rest of us all have to upgrade our software. It's not that the new features don't require me to update, because I've found in the recent months that I actually do have to update.

I admit, this wouldn't be too big a problem at all if codecs all used the same codebase and all had the ability to auto-update. But the reality is that most if not all media players still require you to manually update their codecs from time to time. Certainly on the Xbox, whenever I have to update it, it's a half hour job to get the new versions of XBMC, update my config so that it works on the new version and upload the whole thing to the Xbox.

I think a standalone web site which does all the gruntwork of converting H.264 to more mature formats would actually be a good idea, and would stop a lot of the bickering which is bound to ensue as more and more groups catch onto H.264.

If nothing else, it takes a lot of the sting off people using non-upgradeable video players. I've heard many opinions voiced here and elsewhere that "anyone with a 900MHz CPU should be able to upgrade to H.264." Well, my Xbox ain't being upgraded without some kind of overclocking and liquid cooling. ;-)

Last edited by Trejkaz; 2006-02-05 at 07:45.
Trejkaz is offline   Reply With Quote
Old 2006-02-05, 08:29   Link #256
Eeknay
Gendo died for your sins.
*Fansubber
 
 
Join Date: Dec 2005
h264 plays on the Xbox just fine. I'm pretty sure it can just about decode ~400p (when I say that, I mean widescreen, so 640x480 would probably work fine [I'm not an expert]), maybe a bit more. I've seen plenty of h264 encodes on Usenet that are specifically designed to be Xbox compatible.

EDIT: Here's an example'

Quote:
Codec: Nero Digital (AVC/H.264)
Container: MP4
Video bitrate: Average bitrate 1307 kbps - Max Bitrate 5747 kbps
Audio: LC-AAC 5.1-channel Average bitrate 186 kbps - Max Bitrate 227 kbps
Video resolution: 720x408 (square pixel)
File Size: 851MB
Subtitles: English (vobsub)

Rate Control: High quality encoding (2-pass)

(GENERAL SETTINGS)
Decision quality: High Quality (maximum)
Maximum vector range: -512 to 511.75
Maximum reference frames: 2
Maximum GOP size: 300
Maximum B-frames: 3

(ENCODING TOOLS)
CABAC: No
Bidirectional prediction: Yes
Macroblock partitions: No
Weighted prediction: No
Deblocking: No

(VISUAL ENHANCEMENTS)
Source material: Chroma optimization
Psycho-visual enhancements: High

------------------------------------------------------------------
IMPORTANT INFO FOR XBOX USERS:

The cache settings are really important to play AVC files without problems. These are the settings
I use. But it is important to know that I'm only playing movies from dvd or harddisk. I adjusted my
cache settings according to that.

Video/Audio/DVD Cache - harddisk 4096 KB
Video Cache - DVDRom 7164 KB
Audio Cache - DVDRom 256 KB
DVD Cache - DVDRom 4096 KB

ALL OTHER PARAMETERS 0 KB

Some other important settings I use:
- High Quality Pixel Shader
- Every FTP or internet connection disabled
- Smoothed A/V synchronization enabled (IMPORTANT!!)
- No post-processing
Ok, so the settings he used aren't exactly fancy or quality based, but my point still stands; h264 on xbox can work.

Now, a question for those who do keep up with xbox modding/playback etc... can CoreAVC be used as a decoder on the xbox, and if it can, what are the results?
Eeknay is offline   Reply With Quote
Old 2006-02-05, 08:43   Link #257
Quarkboy
Anime Translator
 
 
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 35
Send a message via AIM to Quarkboy
Quote:
Originally Posted by Trejkaz
So you're saying what I said isn't true, but then saying it is true.

I said: "the codec changes so often that a video encoded with today's version won't work on one from a week ago."

These new options are exactly what cause the problem. As soon as someone encodes a video using a new feature of the codec, the rest of us all have to upgrade our software. It's not that the new features don't require me to update, because I've found in the recent months that I actually do have to update.
No, you don't understand. Those new options do nothing to decoding capability. They effect the quality of the of the encodes, but not the way they are played back. Just as whether an encoder used 1 or 2 passes doesn't change whether the video is playable or not, only how good quality it is.

Options like --bime or --mixed refs do not use any new codec "features"... they essentially increase the amount of searching the codec does in the video to determine the optimal compression. It's like the difference between the search precision settings on xvid... changing them doesn't change the playback compatability.

Like I said, no options have been added that would make YOU have to change your decoding software since about august. An august ffdshow build could play back encodes done today, with the latest x264.

If you've had compatabilty problems, it's most likey has nothing to do with h264 at all... it's probably more likey an mp4 muxing issue, which is changing a bit lately. However even in that case, it's not because standards are changing, it's because programs like vlc had bugs that are only now being fixed.
__________________
Yomiuri Television Enterprise
International Media Strategy Chief
Sam Pinansky
Quarkboy is offline   Reply With Quote
Old 2006-02-05, 09:17   Link #258
TheFluff
Excessively jovial fellow
 
 
Join Date: Dec 2005
Location: ISDB-T
Age: 28
What Quarkboy said. The MPEG specifications say nothing about how an encoder is supposed to behave (even if there is a reference encoder), they only specify what the resulting bitstream should look like. Hence, as long as the both the decoder and the encoder are fully MPEG4 Part 10-compliant, it won't matter which versions of them are used. The problem is that not all decoders/encoders implement the full AVC spec, or even do it correctly... On the encoding side, the only thing that x264 doesn't do yet is interlaced encoding, AFAIK (and noone uses that anyway). On the decoding side, it's pretty much the same with libavcodec (which is what XBMC and mplayer and ffdshow and about everything else open source uses for decoding) - the only unsupported feature is interlaced decoding (again, to the extent of my knowledge - I haven't looked at it much recently so I might remember wrong).

@Eeknay: That's interesting, but... no CABAC and no inloop deblocking? Ugh. 5.1 LC-AAC at that bitrate isn't likely to sound very nice, either... XviD+AC3 is probably a better alternative for quality with those limitations...
__________________
| ffmpegsource
17:43:13 <~deculture> Also, TheFluff, you are so fucking slowpoke.jpg that people think we dropped the DVD's.
17:43:16 <~deculture> nice job, fag!

01:04:41 < Plorkyeran> it was annoying to typeset so it should be annoying to read
TheFluff is offline   Reply With Quote
Old 2006-02-05, 09:35   Link #259
Green²
It's Magic
 
 
Join Date: Nov 2003
Location: Up and to the Left
Age: 34
H.264

Take note that with TCPMP/CoreAVC, with some of the Arienai H.264 encodes for example, I've seen decoding processor usage on an Celeron 2.2GHz drop from ~85% /peak 100% (ffdshow), down to ~20% /peak 45% (TCPMP/CoreAVC). Generally meaning that with time given, there is the potential that you'll see with an lot of builds, whatever codec in this case, reach decoding speeds probably many times faster than what they are at now. ...at least in theory to that TCPMP/CoreAVC has shown such decoding speeds possible.
Green² is offline   Reply With Quote
Old 2006-02-05, 10:16   Link #260
Soluzar
Senior Member
 
 
Join Date: Dec 2005
Location: Derby, UK.
Age: 39
Send a message via AIM to Soluzar Send a message via MSN to Soluzar Send a message via Yahoo to Soluzar
Quote:
Originally Posted by Quarkboy
http://en.wikipedia.org/wiki/Blink_tag

I figured there'd be a wikipedia article on it, and I was right.

When I say "banned" I was being a bit overly emphatic. Suffice it to say that if your webpage has a lot of "blink" tags, most people consider that in terrible taste.
Oh, I thought you were talking about something more along the lines (however unlikely it might seem) of actual consequences resulting from the use of it. I don't really know what I was thinking. Having never come across the "blink" tag, I was entirely unaware that it existed.
__________________
Richard Taylor

The Crumbling Biscuit.
Soluzar is offline   Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 14:44.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
We use Silk.