Vài vấn đề linh tinh liên quan đến DTS

Nhầm lẫn nhỏ về core của DTS-HD MA và TrueHD: DTS-HD MA bao gồm lossy DTS core và phần mở rộng. Phần core có thể tách rời và giải mã độc lập. Tuy nhiên, để giải mã DTS-HD MA nhất thiết phải có cả core lẫn phần mở rộng. Ngược lại, TrueHD không hề có core. Trên Blu-ray, mỗi TrueHD track theo quy định luôn phải kèm theo một AC-3 track (gọi là embeded track) dùng làm fallback trong trường hợp thiết bị phát không hỗ trợ giải mã TrueHD. AC-3 track này hoàn toàn độc lập và tách rời với TrueHD track (mặc dù nó được gọi là embeded track) AC-3 frames được xếp xen kẽ với TrueHD frames, tuy nhiên việc giải mã chúng hoàn toàn độc lập và tách rời. TrueHD không phụ thuộc/không cần đến AC-3 track để có thể giải mã.

DTS và AC-3: AC-3 (Dolby Digital) được thiết kế có hiệu quả nén cao hơn DTS rất nhiều. Khi thực hiện double-blind test, nhiều người nhận thấy AC-3 640 Kbps thường cho chất lượng gần tương đương với DTS 1.5 Mbps (tất nhiên với điều kiện chúng đều encode cùng nguồn bằng encoder tốt). Vì vậy dùng AC-3 tiết kiệm dung lượng hơn. Tuy nhiên ưu điểm của DTS là khả năng lưu trữ thông tin dynamic và tín hiệu bass/surround tốt hơn (ngoài ra, DTS cũng thường được encode bằng bản mix có âm lượng lớn hơn, nhất là phần bass và surround, khiến cho người nghe thường có cảm giác rằng nó "nghe hay hơn"). Việc đánh giá cái nào tốt hơn do đó thường mang tính chủ quan và cảm tính, tùy thuộc vào "thính" hiếu và thiết bị âm thanh của mỗi người. Dù sao thì AC-3 vẫn kém hiệu quả hơn nhiều so với một số chuẩn nén âm thanh khác (? vẫn còn tranh cãi) như AAC, Vorbis hay Opus, nhưng nó và DTS vẫn được chọn nhiều hơn bởi tính tương thích cao.

DTS và FLAC (hoặc lossless nói chung): FLAC nếu được encode từ DTS-HD MA (sau khi dither xuống 16-bit) thường có dung lượng gần bằng với DTS core của DTS-HD MA track đó, trong khi cho chất lượng gần bằng DTS-HD MA (vì khác biệt giữa 24-bit và 16-bit dithered từ 24-bit hiện tại còn khó nhận ra). Tuy nhiên, bởi vì bản thân DTS core và DTS-HD MA vốn không mấy khác biệt khi nghe trên dàn âm thanh hạng trung trở xuống, các "release group" thường chọn DTS thay vì FLAC nếu họ quan tâm đến tính tương thích.

DTS không phải là lossless: Đừng nhầm lẫn với phiên bản mở rộng DTS-HD MA, bản thân DTS chưa bao giờ là lossless. Thậm chí DTS còn nằm trong số các chuẩn nén âm thanh lossy kém hiệu quả nhất. Thường thấy ở các diễn đàn chia sẻ dữ liệu, các uploader đăng các DTS Audio CD vào các box lossless và các mem do đó cứ cho rằng chúng là lossless (Cũng dễ hiểu vì nhiều người thậm chí không biết thuật ngữ "lossless" là cái khỉ gì! Họ thậm chí cho rằng chỉ WAV/CD Rip hoặc DTS Audio CD/DTS-WAV mới là lossless).

Vài nguyên tắc khi encode với x264

Để bản encode bằng x264 đạt chất lượng chấp nhận được thực sự không khó, chỉ cần tuân theo vài nguyên tắc hết sức cơ bản. Đáng tiếc vẫn có người không nắm được.

Trước hết cần làm rõ chất lượng "chấp nhận được" là chất lượng người đánh giá thấy... chấp nhận được. Nghĩa là nó mang tính cảm tính. "Chấp nhận được" với người này có thể là phải gần giống y chang source nhưng với người khác lại là tồn tại một số hay thậm chí nhiều artifact nhưng có thể bỏ quá, và khoảng giữa đó.

Lưu ý: Các nguyên tắc nêu dưới đây chưa tính đến chất lượng source. Chúng chỉ đảm bảo chất lượng "chấp nhận được" khi so sánh giữa source (dùng làm input) với output, trong khi output tốt hay xấu còn tùy vào source. Bài viết không bàn đến việc nâng cao chất lượng source cũng như cách đánh giá chất lượng một bản encode.

Các nguyên tắc chung:

• Dùng tune phù hợp với kiểu source cần encode.

• Dùng preset chậm nhất có thể chấp nhận được (tùy vào thời gian encode mong muốn, năng lực xử lý máy tính...) nhưng không cần dùng tới placebo, trừ khi không ngại việc phí thời gian cho thêm một tý chất lượng. Đối với các bản encode mong muốn dùng để lưu trữ, tốt nhất đừng nên dùng preset nhanh hơn medium, trừ khi không ngại tốn dung lượng. (Nếu cảm thấy preset medium vẫn quá chậm thì đừng nên encode. Cũng nên biết rằng nếu quan tâm đến chất lượng thì 5 fps chưa gọi là chậm).

• Encode ở chế độ CRF, trừ khi thật sự cần phải xác định dung lượng. CRF giúp cho các bản encode có chất lượng đồng đều, đồng thời tiết kiệm thời gian (hoặc nếu không cần thời gian tiết kiệm được có thể dùng preset chậm hơn). Chọn một giá trị CRF phù hợp bằng cách encode thử một số nội dung ở CRF khá thấp, ví dụ 15, sau đó tăng dần lên đến mức artifact bắt đầu gây khó chịu (hoặc chất lượng không còn "chấp nhận được") nhằm xác định giá trị CRF mong muốn. Sau đó cứ việc dùng giá trị CRF đó cho những source khác có độ phức tạp tương đương. Khi encode cho số đông, cố gắng chọn giá trị trung hòa giữa chất lượng và dung lượng, sao cho cả hai có thể "chấp nhận được" với đa số.

• Nên nhớ 3 điều sau có mối tương quan chặt chẽ: chất lượng, thời gian encode, dung lượng. Cùng chất lượng, thời gian encode tỷ lệ nghịch với dung lượng. Cùng thời gian encode, chất lượng tỷ lệ thuận với dung lượng. Cùng dung lượng, chất lượng tỷ lệ thuận với thời gian encode.

• Chỉ tùy chỉnh các parameter khi biết rõ chúng sẽ tác động thế nào lên sản phẩm cuối. Nếu không cứ để mặc định. (Nghĩa là đừng nên copypasta random settings thu nhặt được từ các tut/guide). Nên tham khảo cách dùng các parameter này từ các nguồn đáng tin cậy, ví dụ từ --fullhelp, từ trang này, từ các post của các thành viên uy tín của Doom9, Doom10...

• Nếu source là anime nên dùng 10-bit trừ khi thực sự quan tâm đến vấn đề tương thích.

Anime chỉ dành cho con nít

Có một hiện tượng phổ biến là ở các diễn đàn không chuyên về anime, hễ có ai đăng chia sẻ anime là các bác phụ huynh nhà ta nhao nháo vào "down về cho con xem", "load về cho em/cháu xem"... chẳng cần biết nội dung anime có phù hợp với lứa tuổi con cháu mình hay không. Tình trạng vô tư này dẫn đến nhiều hệ lụy mà điển hình là vụ phụ huynh "tá hỏa" phát hiện con cháu mình xem nội dung "hoạt hình" không phù hợp, kế đến báo chí đăng loạt bài "lên án" anime và các diễn đàn chia sẻ anime mà quên mất góp phần không nhỏ trong việc truyền bá nội dung "độc hại" cho giới trẻ nước nhà là các bậc phụ huynh thiếu ý thức. (Ý thức người xem và những vấn đề linh tinh khác tôi không muốn đề cập tới).

Cớ gì lại giấu x264 settings?

Nếu ai từng sử dụng x264 để encode có lẽ biết rằng mặc định chương trình sẽ ghi lại settings và version sử dụng (user data) vào trong SEI (một phần header của bitstream). Việc này trước hết giúp cho các developer của x264 dễ dàng debug khi có người dùng báo lỗi. Về sau, thông tin này còn giúp những người dùng kinh nghiệm xem lại settings mình từng sử dụng. Tất nhiên là cũng biết được settings mà người khác sử dụng cho bản encode nào đó.

Tại sao "pirate" chủ yếu dùng x264?

Các người làm trong lĩnh vực authoring khi được hỏi sao không sử dụng x264 thường cho rằng như thế không "pro", không chuyên nghiệp. Họ viện nhiều cớ này nọ để thoái thác, như x264 không bằng một số sản phẩm chuyên nghiệp ở bitrate cao, khách hàng sẽ không hài lòng khi biết họ dùng phần mềm miễn phí (tâm lý "tiền nào của nấy"), việc sử dụng x264 không tiết kiệm nhiều chi phí trong khi đòi hỏi nhân viên phải được đào tạo lại (lý do x264 khó sử dụng và không đảm bảo tạo ra stream tương thích với chuẩn), x264 không kèm theo đầy đủ công cụ cho toàn bộ quá trình authoring như các sản phẩm chuyên nghiệp...

Tôi không muốn bàn đến những điều này. Từng sử dụng thử MainConcept tôi thừa nhận x264 tồn tại một vài yếu điểm so với MC ở mức bitrate cao, chẳng hạn vấn đề banding, hoặc cảnh chuyển động nhanh, tuy nhiên vì bitrate cao nên chênh lệch giữa chúng cũng rất khó nhận thấy. Và đúng rằng x264 không hỗ trợ tốt các công đoạn mà authouring đòi hỏi. Cho nên không phải nói rằng họ không có lý. Điều làm tôi khó chịu nhất là họ thường xuyên dùng luận điệu rằng x264 chỉ và sẽ chỉ phổ biến trong giới pirate là vì nó miễn phí nên giúp cho việc pirate phim thuận lợi hơn. Cực kỳ lố bịch! Vì sao? Vì nó áp dụng lên "pirate"! Pirate không quan tâm chuyện miễn phí hay không, nếu muốn họ có thể pirate hoặc thậm chí mua phần mềm chuyên nghiệp nếu thật sự cần thiết*. Điều làm cho x264 trở nên phổ biến đối với người dùng thông thường và "pirate" là vì trên thực tế họ thấy rằng x264 thể hiện chất lượng ưu việt hơn hẳn các H.264 encoder khác ở mức bitrate trung bình (1/3 bitrate thường dùng trên Blu-ray) trở xuống. Tất nhiên, đúng rằng việc này thuận lợi cho việc trao đổi qua mạng và lưu trữ, nhưng cũng không vì thế mà phù hợp với luận điệu họ đưa ra.

---

* Lưu ý: Ở đây không nói đến các phần mềm authouring (như Blu-Code), bởi vì chúng không có bản bẻ khóa (do khâu licensing khắc khe) và có giá rất cao, mà muốn nói đến các phần mềm H.264 encoding thương mại thông thường (đa số dùng MainConcept) ví dụ Rovi TotalCode Studio, Harmonic ProMedia Carbon (tên cũ: Rhozet Carbon Coder), Elecard StreamEye series, Elecard Converter Studio, Ateme EAVC4...

Chút thông tin cập nhật về tình hình cá nhân và blog

Bởi lẽ lâu rồi không đăng thêm bài nào mới nên tôi muốn lý sự giải thích một chút. Mà thật ra thì hầu như chẳng ai đọc blog này ngoài tôi nên... viết cho có thôi!

Có thể có người biết hoặc... không biết rằng hiện tại tôi đang bận tối tăm mặt mũi nên không có thời gian "rảnh" nào dành cho các sở thích cá nhân, trong đó có việc viết blog. (Trên thực tế, việc viết blog có mức ưu tiên thấp nên ngay cả tôi có thời gian "rảnh" cũng chưa chắc... đến lượt nó). Do đó mà blog sẽ không có thêm bài viết mới cũng như cập nhật, thay đổi gì trong một khoảng thời gian dài (hoặc ngắn) sắp tới. Tuy vậy, điều đó không đồng nghĩa với chuyện blog này sẽ "chết", và tôi cũng vậy (xin lỗi nếu làm bạn thất vọng; mà xét kỹ thì trước sau gì tôi cũng sẽ chết, chỉ là chưa phải lúc này)!

Giờ thì sao?

Tôi chưa bao giờ tính đến chuyện tên miền ở Dot TK của mình lại bị suspend (và lần lượt hết cái này đến cái khác). Sau khi chuyển host, tôi tưởng đâu không gì phải lo nữa, ít nhất là một thời gian dài. Không dè người tính không bằng Trời tính. Ngoài ra, tài khoản Mediafire của tôi cũng đã bị khóa. Nhưng... chuyện này thì có ảnh hưởng gì lớn?

Vâng, blog này thì vẫn còn nằm nguyên đây nhưng những đường link trước kia dẫn đến nó không còn hiệu lực vì dùng tên miền khác. Đó chỉ là một chuyện. Có thể một số các bạn biết rằng tôi (từng) thuộc "nhóm fansub một thành viên" gọi là Henjin (tên cũ TheWeirdo). Tuy rằng đã chính thức tuyên bố "giải nghệ", thật ra tôi vẫn không quên được thói quen làm fansub nên dự định sẽ "tung ra" vài project nữa trong tương lai. Thậm chí ít nhất hai trong số đó đã đang "work in progress" trước khi chuyện mất tên miền xảy ra. Nhưng rồi việc xảy ra làm tôi mất hứng hẳn. Đồng ý rằng tôi vẫn có thể đăng fansub của mình ở VnSharing (trên thực tế phần lớn fansub của tui đều có đăng ở đó), nhưng có vài bất tiện, đặc biệt là tôi thích được "làm chủ một góc Trời" hơn, bên cạnh đó là tôi có thể đăng những thứ linh tinh khác ngoài fansub.

Thật ra thì việc đăng ký tên miền mới rồi setup lại một weblog không phải là chuyện quá khó khăn, nhưng vẫn tốn thời gian và công sức, chưa kể để tránh những rắc rối tương tự trong tương lai tốt nhất tôi nên bỏ tiền ra thuê tên miền và host, rồi tìm cách để người ta biết đến địa chỉ mới... Nói chung là nhiêu khê và chẳng thú vị gì.

Vậy thì sao? À, không có gì quan trọng cả. Chỉ là cho những ai từng biết đến "nhóm" Henjin (hay TheWeirdo) biết rằng chuyến này "nhóm" đã thực sự "về hưu". Một phần vì tôi mất động lực làm tiếp, một phần vì những rắc rối đời tư, và thêm chuyện này nữa có lẽ là dấu hiệu báo rằng tôi nên từ bỏ.

Hết.

Chuyện gì đã xảy ra với tên miền the-weirdo.tk

Nói thật tôi cũng chẳng biết chuyện gì đã xảy ra (!), chỉ biết là sáng hôm đó, như thông lệ, tôi vẫn truy cập bình thường được vào the-weirdo.tk/wp-admin nhưng đến gần tối khi định đăng nhập điều chỉnh vài trang thì trình duyệt báo lỗi không truy cập được. Sau đó không lâu, khi truy cập trực tiếp vào the-weirdo.tk thì bị chuyển đến một trang lạ hoắc kentils.net nào đó (mà hầu như không có nội dung gì).

Một thông báo từ CoreCodec

Chúng tôi ở CoreCodec xin vui mừng thông báo:

Chỉ sau hơn 9 tháng, phiên bản 3.1 cập nhật và sửa lỗi cho CoreAVC 3.0.1 sắp sửa được phát hành (mặc dù đây không phải thông tin mới mẻ gì bởi vì chúng tôi đã thông báo điều này ít nhất 2 lần cách nhau mỗi 3 tháng, và có thể 3 tháng sau chúng tôi sẽ thông báo lại thông báo này nữa). Chúng tôi xin chân thành cảm ơn những người dùng ngu xuẩn và ấm đầu, à không, trung thành và kiên nhẫn đã chịu đựng một sản phẩm nhiều lỗi và hiệu năng kém trong suốt 9 tháng qua mà không chịu chuyển sang dùng các sản phẩm miễn phí tương tự có tính năng ưu việt hơn, sửa lỗi nhanh hơn và hiệu năng tốt hơn. Do đó chúng tôi cam kết sẽ nỗ lực kéo dài thời gian phát hành phiên bản mới hơn nữa để người dùng có được sự trải nghiệm thử thách lòng kiên nhẫn tốt nhất. Vì lẽ đó, chúng tôi không biết được khi nào phiên bản 3.1 sẽ đến được tay người dùng. Tuy nhiên, chúng tôi sẽ cố gắng phát hành nó trước Tết Công Gô (nếu chúng tôi biết được Tết Công Gô diễn ra vào ngày nào). Xin các bạn hãy tiếp tục chờ đợi và nhớ đón đọc thông báo tương tự sau 3 tháng nữa nếu khi đó CoreAVC 3.1 vẫn chưa phát hành.

*Lưu ý: Thông báo trên đây tất nhiên không phải là thật (mặc dù những gì nó nêu là thật). Phiên bản nói đến trong thông báo là phiên bản DirectShow filter dành cho consumer, không phải SDK, vì CoreAVC SDK 3.1 đã phát hành tuy rằng cũng mất hơn 6 tháng.
*Lý do duy nhất mà tôi chờ CoreAVC 3.1 phát hành là vì CoreCodec hiện đang "thầu" luôn phần phát triển Haali's Media Splitter và họ hứa sẽ phát hành phiên bản sửa vài lỗi khó chịu của nó kèm theo CoreAVC 3.1.

Tám linh tinh: Monmusu Quest!

(Tôi bắt đầu viết bài này cả tháng trước mà đến giờ chưa thể hoàn thành, bởi càng để lâu thì tôi càng quên các chi tiết muốn nói. Nay tôi quyết định đăng luôn dù nó còn khá dở dang).

Sau khi hoàn thành Katawa Shoujo, tôi không nghĩ rằng mình sẽ "chơi" visual novel (VN) nữa chỉ sau thời gian ngắn. Bởi lẽ VN khá ngốn thời gian (tất nhiên tôi biết là còn tùy, không phải VN nào cũng có độ dài như Katawa Shoujo, một số khá ngắn, số khác thậm chí dài hơn) mà thời gian là thứ tôi thiếu thốn thứ ba (sau tiền và tình!). Tuy nhiên Katawa Shoujo phần nào làm cho tôi có hứng thú với VN nên mỗi khi bắt gặp VN hoặc liên quan đến VN tôi không làm ngơ như trước mà thường ngó qua thử.

Tám linh tinh: Mass Effect universe

Mass Effect 3 đã phát hành, kết thúc Mass Effect trilogy xoay quanh Commander Shepard. Tuy rằng theo BioWare, Mass Effect universe vẫn chưa kết thúc tại đây (bên cạnh DLC, comic, anime, mobile game thì nhiều khả năng sẽ có phần 4 hay thậm chí hơn, tất nhiên là câu chuyện khác). Dù vậy, đây là lúc thích hợp để tám nhảm về những chi tiết linh tinh quanh Mass Effect series.

Tám linh tinh: Mass Effect 3

Bài viết này là để ghi lại các cảm nhận trong quá trình chơi game hoặc các chi tiết đáng chú ý trong game.

Tám linh tinh: Mass Effect 3 Ending

Sau khoảng hơn 30 giờ chơi, tôi hoàn thành Mass Effect 3, khép lại Mass Effect trilogy. Trong khi phần 3 hấp dẫn không thua kém hai phần trước nếu không nói là hơn, "diễn xuất" cùng phần lồng tiếng của phần lớn nhân vật xuất sắc, gameplay cải tiến, các tình tiết sắp xếp hợp lý, nhiều quyết định của hai phần trước lần lượt thể hiện ảnh hưởng đến các sự kiện trong phần này, cốt truyện ly kỳ, kịch tính, lôi cuốn. Có thể nói rằng, tuy còn tồn tại một số lỗi nhỏ và chi tiết vụn vặt gây khó chịu (trong cả kịch bản, đồ họa, gameplay, cơ chế điều khiển), Mass Effect 3 là một game hành động-nhập vai tuyệt vời. Ít ra là cho tới khi trước Ending. Tại sao lại nói vậy? Bởi vì Ending rất đáng thất vọng. Mặc dù chỉ mới chơi qua một Ending (chọn điều khiển Reaper; ở vòng chơi thứ hai tôi lựa chọn Synthesis; tôi không muốn chọn tiêu diệt toàn bộ synthetic vì tôi có thiện cảm với đám geth và EDI), dựa theo thông tin từ Net, các Ending còn lại cũng chẳng khá gì hơn. (Tệ hơn, chúng hầu như chẳng khác nhau, ngoại trừ việc họ dùng ba màu khác nhau [RGB] cho mỗi lựa chọn, và thay đổi chút ít chi tiết tùy vào số EMS trước khi bắt đầu Priority: Earth, điều này trái hẳn với những gì Executive Producer Casey Hudson từng hứa hẹn: "It’s not even in any way like the traditional game endings, where you can say how many endings there are or whether you got ending A, B, or C…The endings have a lot more sophistication and variety in them.").

Nén lossless: Bitrate có ý nghĩa gì đến chất lượng không?

Trả lời cho câu hỏi trên tiêu đề là "Không".

Phụ đề không định dạng có liên quan đến độ phân giải video?

Có lẽ cái tiêu đề làm ai đó đọc phải thấy hơi bối rối. Tôi phải thừa nhận rằng mình không giỏi trong việc đặt tên tiêu đề bài viết cho lắm. Tuy nhiên chẳng nên để tâm chuyện đó làm gì, điều tôi muốn nói đến ở đây là tình trạng hiểu sai của nhiều người rằng phụ đề không định dạng như SubRip (.srt), SAMI (.smi)... có liên quan đến độ phân giải của video, trong khi chúng không hề. (Gọi là phụ đề không định dạng đơn giản là để phân biệt với dạng phụ đề chứa thông tin định dạng sẵn như SSA/ASS, chứ không hẳn chính xác, chẳng hạn tùy thuộc vào renderer mà SubRip có thể dùng một số định dạng thông qua HTML tags, phổ biến là Italic, Bold, Color... Bản thân SSA/ASS trước khi render cũng chỉ là plain-text).

Tám linh tinh: Katawa Shoujo

CẢNH BÁO: Một lượng lớn "spoiler" và "tự sướng" ở phía trước!

Tôi bắt đầu viết bài này sau khi hoàn thành được 3 route và đang "chơi" (tôi không biết nên dùng từ gì cho phù hợp, bởi lẽ tôi thấy phần lớn thời gian tôi chỉ đọc chứ có chơi gì) route của Lilly. Đây là lần đầu tôi tiếp cận visual novel, nên đối với thể loại này tôi chỉ là n00b, vì vậy chắc chắn sẽ dùng các thuật ngữ khá buồn cười, chưa kể vì vốn tiếng Anh chỉ ở mức trung bình trong khi vì nhiều lý do khác nhau, tôi không theo dõi kỹ nên nhận xét có thể thiếu hoặc không chính xác. Nhưng đó chẳng phải chuyện tôi quan tâm. Tôi viết bài này cũng như các bài tám linh tinh về anime hay game trước đây, chỉ nhằm thể hiện quan điểm bản thân và giải tỏa, chứ không phải nhằm thu hút hay thể hiện với ai. Hơn nữa, xét về độ nổi tiếng của blog với lác đác vài lượt xem trên tuần thì tôi tin chắc rằng hiếm có ai đọc bài này. Tuy nhiên, (vì blog không đặt ở trạng thái private nên) rồi sẽ có ngày có người tình cờ đọc được. Do đó, tôi cảm thấy vẫn phải nói phòng hờ trước. Ngoài ra, cách viết của tôi thường khá tràn lan, ít tập trung vào vấn đề chính nên đừng ai để ý đến cái tên bài, đơn giản tôi đặt ra để dễ phân biệt và quản lý mà thôi. Nghĩa là trong bài này có thể chỉ có một câu liên quan đến Katawa Shoujo (câu đầu tiên sau dòng "Cảnh báo"), còn lại chẳng ăn nhập gì.

Bạn có rảnh không?

Với tôi, câu trả lời sẽ luôn là: Không!

Gần đây, tôi cảm thấy mình càng ngày càng có ít "thời gian rảnh" nên quyết định xem xét lại lịch sinh hoạt thay đổi thế nào và phát hiện ra rằng thực chất từ trước tới giờ mình không có "thời gian rảnh", theo khái niệm "thời gian rảnh" là thời gian mình không làm gì cả. Bởi lẽ bất cứ lúc nào tôi cũng đang làm gì đó.

"If it ain't broke, don't fix it."

Gần đây khi 10-bit H.264 được giới làm fansub đưa vào sử dụng đã nảy ra nhiều ý kiến phản đối, phàn nàn khiến tôi nghĩ đến chuyện tương tự mỗi khi một thứ mới ưu việt hơn ra đời thay thế cho cái cũ nhưng không tương thích ngược với cái cũ. (Ở bài viết này chỉ muốn nói đến những cái mới mang tính tích cực).

Encoder và chất lượng video của làng fansub Việt - Kỳ 1

Encoder của fansub Việt nhìn chung về cơ bản có thể chia làm 3 dạng: những người vốn có sẵn ít nhiều kiến thức về video/audio processing và encoding, những người không có kinh nghiệm encode được tuyển từ các đợt tuyển quân của các nhóm fansub và các solo fansubber.

Định nghĩa ngắn vài thuật ngữ cơ bản trong lĩnh vực Video/Audio Encoding

Sau đây là định nghĩa ngắn và đơn giản cho một số thuật ngữ thường gặp khi nhắc đến video/audio encoding. Nhiều thuật ngữ trong số này áp dụng chung cho video và audio.