Giới thiệu

Các bài viết sẽ nhằm vào bất cứ đề tài gì mà tôi có hứng thú muốn đề cập, không theo một chủ đề nhất định. Nguyên tắc viết không theo khuôn khổ và tự do thoải mái nhất có thể, nội dung bài viết cũng sẽ thay đổi liên tục theo thời gian nên sẽ rất khó theo dõi. Bên cạnh đó, độ dài của các bài viết rất bất định, nhiều khi dài lê thê và tràn lan.

Các quy tắc chung (Đọc kỹ trước khi quyết định đọc nội dung bài viết):
Điều 1. Nội dung bài viết có thể dựa hoàn toàn vào quan điểm cá nhân, do đó sẽ khác với quan điểm của bạn. Bạn luôn có quyền ngừng đọc hoặc không cần đọc. Tuy nhiên, một khi đã đọc, bạn không được phép tranh cãi với tác giả. (Bạn được quyền nói xấu tác giả, nếu thích). Tác giả không chịu bất cứ trách nhiệm nào nếu nội dung bài viết gây ảnh hưởng xấu đến sức khỏe hay tâm lý của bạn.
Điều 2. Nội dung bài viết có thể chứa rất nhiều "spoiler" nên khuyên bạn không nên đọc trước khi xem/chơi tựa phim/anime/video game... được nhắc đến trong bài viết. Tác giả không chịu trách nhiệm vì làm bạn mất hứng. Bên cạnh đó, vì sở thích mỗi người mỗi khác, những chi tiết mà tác giả chê khen có thể không giống cách đánh giá của bạn, nên đừng dùng nó làm cơ sở lựa chọn. Ngoài ra, xem lại điều 1.
Điều 3. Bài viết chỉ được phép tồn tại trên blog này. Bạn không được quyền sao chép toàn bộ hay một phần nội dung của bất cứ bài viết nào sang nơi khác (bạn được phép đăng link của bài viết đi nơi khác, nếu muốn). Tác giả phủ nhận hoàn toàn trách nhiệm liên quan đến nội dung bài viết nếu nó được phát tán nơi khác dưới hình thức không phải link, tuy nhiên vẫn giữ quyền đối với nó.

2013-08-10

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).

2013-05-09

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.

2013-03-18

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 đó.

2013-03-17

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...

2012-11-27

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)!