abchen
Member
Hôm nay không upload được phim gì mới vì bận thực hiện cuộc phỏng vấn này. Xin phép được chưng lên đây trước vì cộng đồng HD ở nhà mega.1280.com, sau này có cần dọn về khu Kỹ thuật phần mềm hay không thì tùy các mod...
Lỗi bit - chuyện nhỏ mà không nhỏ
Q: bit là gì?
A: bit là đơn vị lưu trữ thông tin cơ bản nhất trên tất cả các thiết bị số.
Mỗi bit chỉ có thể lưu trữ một trong hai giá trị là 0 hoặc 1.
Q: Lỗi bit là gì?
A: Quá đơn giản, lỗi bit xuất hiện khi giá trị đáng lẽ là 0 thì lại là 1 hoặc ngược lại.
Q: Lỗi bit có thể xảy ra khi nào?
A: Lỗi bit có thể xảy ra trong bất kỳ thao tác truyền dữ liệu nào. Đó là trường hợp bị lỗi trên đường truyền.
Ví dụ như trong thao tác upload một file, có ít nhất 3 pha truyền dữ liệu có chứa đựng rủi ro lỗi bit như sau:
Pha 1.Đọc file tại máy trạm: dữ liệu đi từ thiết bị lưu trữ vào bộ nhớ
Pha 2.Dữ liệu truyền từ máy trạm đến máy chủ thông qua kết nối mạng
Pha 3.Lưu file tại máy chủ: dữ liệu chuyển từ bộ nhớ vào thiết bị lưu trữ.
Riêng trong Pha 1 nói trên, nếu phân tích kỹ ra thì nó cũng bao gồm nhiều bước truyền dữ liệu. (Giả sử đọc từ đĩa cứng thì dữ liệu sẽ lần lượt chuyển từ bề mặt lưu trữ qua đầu từ, qua cache của HDC-Hard Disk Controller, qua ATA cable, qua Chipset, qua bus, RAM)
Lỗi bit cũng có thể xuất hiện trong trạng thái dữ liệu tĩnh, đó là trường hợp dữ liệu bị thay đổi ngay trên thiết bị lưu trữ do thời gian hoặc do các tác động của môi trường.
Q: Lỗi bit có thường xảy ra không?
A: Mọi thiết bị lưu trữ cũng như giao thức truyền dẫn đều có công bố tỷ lệ tần suất lỗi dữ liệu như là một chỉ tiêu kỹ thuật bắt buộc. Các thiết bị và giao thức đều có cơ chế tự kiểm tra và sửa lỗi bên trong nên số lượng lỗi có thể ghi nhận từ bên ngoài là rất ít. Tỉ lệ này thường rất nhỏ, chỉ là 1 phần vài chục tới vài trăm tỷ nhưng các bạn nên nhớ rằng cho dù rất rất nhỏ nhưng nó không bao giờ bằng 0. Trong thực tế tỉ lệ lỗi dữ liệu này có khác biệt, ví dụ đối với đĩa cứng, tỉ lệ lỗi được thống kê dựa trên thao tác truy xuất thông thường, nhưng nếu đọc hoặc ghi liên tục một khối lượng lớn dữ liệu thì tỉ lệ lỗi sẽ tăng lên vài lần, nếu việc đảo pha đọc ghi phải thực hiện liên tục mà không có thời gian nghỉ thì tần suất lỗi còn tăng cao hơn nữa.
Q: Lỗi bit có nghiêm trọng không
A: Đứng về góc độ toàn vẹn dữ liệu thì câu trả lời dĩ nhiên là có nghiêm trọng vì trên nguyên tắc, trong thời đại kỹ thuật số này thì bản gốc và bản sao không được phép khác biệt dù chỉ một bit. Nhưng về mặt ứng dụng thì ta cần phân tích kỹ hơn một chút, nhất là khi chúng ta quan tâm đến chất lượng HD.
1.Một phim HD 720p có dung lượng vào khoảng 4,5GB, tương đương với khoảng 38 tỷ bit. Trong các thao tác truy xuất 38 tỷ bit thì việc bị dính bit lỗi cũng bình thường thôi.
2.Bị bao nhiêu bit lỗi thì chấp nhận được? Nhiều hay ít chỉ là khái niệm tương đối, có người từng so sánh là 500 sợi tóc là ít nếu chúng mọc trên đầu - còn nếu trong tô phở thì chỉ 2 sợi cũng đã là nhiều.
3.Một lỗi bit có thể gây hậu quả gì? Tùy vào vị trí xuất hiện của nó, lỗi bit sẽ làm thay đổi trị số kỳ vọng:
Nếu dữ liệu là 1 byte (8-bit) thì giá trị nhận được có thể chênh lệch đến 128 đơn vị so với giá trị thật.
Nếu dữ liệu là 1 word (16-bit) thì giá trị nhận được có thể chênh lệch đến 32768 đơn vị so với giá trị thật.
Nếu dữ liệu là 1 lword (32-bit) thì giá trị nhận được có thể chênh lệch đến 2147483648 đơn vị so với giá trị thật.
...
Đối với nhu cầu thưởng thức phim HD, tùy vào vị trí xuất hiện của lỗi mà việc trình diễn có thể gặp những phiền toái sau đây:
- Sai màu
- Ca rô
- Giật hình / giật tiếng
- Đứng hình / đứng tiếng
- Tự động quay lại từ đầu / hết phim đột ngột
- ...
Từ những phân tích trên thì ta có thể tóm lại là lỗi bit không quá nghiêm trọng đối với phim HD nhưng nó sẽ làm người xem ngứa mắt, bực mình, thậm chí lên tăng xông nếu hình bị đứng ngay cảnh "nóng"...
Q: Vậy có cách nào để phát hiện lỗi bit không?
A: Có chứ, thậm chí có nhiều cách nữa là đằng khác, mỗi cách có ưu và khuyết điểm riêng. Cách đơn giản nhất là so sánh lại với bản gốc sau khi sao chép xong (dùng lệnh [fc /b] trong cửa sổ console chẳng hạn) nhưng cách này chắc chắn không ai dùng vì vô cùng tốn tài nguyên. Hiện tại phương pháp kiểm tra toàn vẹn dữ liệu bằng mã kiểm tra là thông dụng nhất. Nguyên tắc chung của các phương pháp này như sau: toàn bộ dữ liệu nguồn được sử dụng để tính toán ra một mã kiểm tra, toàn bộ dữ liệu đích cũng được tính toán bằng một giải thuật tương tự, sau đó so sánh 2 mã kiểm tra sau 2 quá trình trên để kết luận dữ liệu đích có hoàn toàn giống với dữ liệu nguồn hay không. Tùy giải thuật tính toán và kích thước của mã kiểm tra ta sẽ có tên gọi của các phương pháp riêng biệt; các phương pháp này được đánh giá và so sánh với nhau dựa trên tốc độ xử lý và độ tin cậy. Có thể kể ra một số phương pháp cụ thể như sau checksum, CRC8, CRC16, CRC32, MD2, MD4, MD5, Adler32...
Q: Phương pháp phát hiện lỗi nào là tốt nhất?
A: Các phương pháp phát hiện lỗi phải cân đối giữa tốc độ và độ tin cậy. Tốc độ tính toán tùy thuộc vào các công thức, độ phức tạp của giải thuật, số lần quét dữ liệu... Còn độ tin cậy chính là xác suất bỏ sót lỗi. Ở câu trả lời bên trên, tôi có nhắc tới cách so sánh lại với bản gốc sau khi sao chép xong (dùng lệnh [fc /b]), thực chất có thể coi đây là phương pháp kiểm tra mã toàn phần với độ tin cậy cao nhất nhưng tốc độ thì tệ nhất. Trong khi vẫn tiếp tục tìm kiếm phương pháp tốt nhất, hiện ta chỉ có khái niệm phương pháp phổ biến nhất mà thôi, đó là những phương pháp đã được chứng thực và áp dụng trong thực tế như CRC32, MD5, Adler32... trong đó CRC32 là một phương pháp truyền thống được sử dụng trong nhiều phần mềm, giao thức truyền thông và kể cả tích hợp trong phần cứng.
Q: Phương pháp kiểm tra lỗi bằng CRC32 có đánh tin cậy không?
A: CRC32 là mã kiểm tra có kích thước 32 bit, thường được biểu diễn bằng 1 dãy 8 ký số thập lục phân, mã được phát sinh do một giải thuật cộng dồn chọn lọc bit có gia số. Mã CRC32 có tốc độ tính toán nhanh và độ tin cậy tốt. Có bạn sẽ nghi ngờ về độ tin cậy của CRC32 vì theo nguyên lý Đi-rích-lê, mã CRC32 có thể mang 4294967296 trị số khác nhau nên chỉ cần 4294967297 tập tin khác nhau sẽ có ít nhất hai tập tin cho cùng một mã CRC32. Tuy nhiên đó là một xác suất rất nhỏ trong thực tế. Ta hoàn toàn có thể yên tâm là hai tập tin cùng kích thước sẽ là đồng nhất nếu chúng cho cùng một mã CRC32. Hay nói cách khác, nếu trong tập tin có xuất hiện lỗi bit theo phân hoạch và tần suất ngẫu nhiên thì chắc chắn ta sẽ thu được một mã CRC32 khác.
Q: Mã CRC32 được vận dụng như thế nào trong việc chia sẻ phim trên mạng?
A: Mã CRC32 là một công cụ hữu hiệu để đảm bảo sự toàn vẹn của dữ liệu qua các quá trình sao chép, tải lên, hoặc tải xuống từ internet. Tôi đã xây dựng một quy trình kiểm tra bằng mã CRC32 để bảo đảm tập tin cuối cùng trên máy của bạn hoàn toàn đồng nhất với tập tin gốc trên máy của tôi. Quy trình này như sau:
Bước 1:Chuẩn bị tập tin MKV
Tiến hành lấy mã CRC32 của tập tin nguyên thủy. Phải lấy ít nhất 2 lần để đảm bảo mã CRC32 đó là chính xác. Lỗi bit cũng có thể xảy ra khi bạn đọc tập tin để tính CRC32, do đó nếu có 2 lần đọc cho ra cùng một mã CRC32 thì mã đó đáng tin cậy hơn rất nhiều lần. Đặc biệt nếu tính mã CRC32 nhiều lần mà mỗi lần được một kết quả khác nhau thì bạn phải xem lại chất lượng của thiết bị lưu trữ và/hoặc RAM.
Chú ý! Nếu lỗi bit đã có sẵn trong tập tin MKV nguyên thủy thì quy trình này không hề có công dụng khắc phục hay sửa chữa điều đó.
Bước 2:Cắt tập tin thành nhiều phần nhỏ
Sử dụng phần mềm WinRAR để xử lý tập tin với những thông số cố định để sau này có thể thực hiện lại nếu cần:
- Archive format: RAR
- Compression method: Store
- Checked: Put recovery record
- Split to volumes, byte: 209,715,200
- Recovery record: 1 percent
Bước 3:Kiểm tra chất lượng của Bước 2
Dùng WinRAR mở part cuối lên kiểm tra mã CRC32 của WinRAR đã tính có trùng với mã CRC32 trong Bước 1 hay không. Sau đó (tùy chọn) dùng chức năng Test của WinRAR xem có thành công hay không.
Nếu không qua được Bước 3 này thì phải làm lại Bước 2.
Bước 4:Lấy mã CRC32 của tất cả các part đã tạo ra ở Bước 2
Cũng phải lấy tối thiểu 2 lần theo nguyên tắc đã trình bày trong Bước 1.
Bước 5:Tải các part lên máy chủ (Tôi tải lên mega.1280.com)
Bước này thực hiện như bình thường, không có bí quyết gì đặc biệt. Tôi thường mở 3 - 4 trang Multi Upload cùng lúc, mỗi trang tải được 8 part, cắm máy qua đêm...
Bước 6:Tải tất cả các part đã up ở Bước 5 về máy
Bước này cũng đơn giản, đẩy vào IDM rồi ngồi làm việc khác trong thời gian chờ đợi.
Bước 7:Kiểm tra chất lượng các part
Lấy mã CRC32 của mỗi part vừa tải về trong Bước 6 và so sánh với kết quả của Bước 4. Khớp thì tốt còn nếu không khớp thì thử tính mã CRC32 một lần nữa xem sao, nếu vẫn không khớp thì quay lại thực hiện từ Bước 5 đối với part đó.
Bước 8:Gửi bài giới thiệu lên diễn đàn
Tôi chỉ gửi bài giới thiệu lên diễn đàn sau khi đã kiểm tra tất cả các part sau Bước 7. Các lỗi về sau hoàn toàn do quá trình lưu trữ của máy chủ hoặc do quá trình tải về.
Q: Quả là một quá trình công phu và tiêu tốn khá nhiều thời gian cũng như dung lượng trống của đĩa cứng. Vậy quy trình này sẽ giúp gì cho những người tải xuống?
A: Có thể bạn nghĩ tôi "trùm sò", nhưng việc áp dụng quy trình này sẽ đảm bảo không để rơi rớt dù chỉ một bit... (cười). Khi gửi bài giới thiệu và liên kết để tải về, tôi cũng đồng thời công bố mã CRC32 của mỗi part. Vậy khi tải được một part về, bạn chỉ cần tính mã CRC32 của part đó là biết ngay quá trình tải có bị lỗi hay không (để tránh bị lỗi giả do quá trình đọc tại máy của bạn, bạn nên tính lại mã CRC32 một lần nữa nếu lần đầu chưa khớp). Việc kiểm tra lại bằng CRC32 rất có lợi về mặt thời gian: thứ nhất do quá trình tính CRC32 khá nhanh, thứ hai là bạn có thể kiểm tra độc lập từng part thay vì dùng chức năng Test của WinRAR luôn bắt đầu từ part đầu tiên.
Q: Ồ! Công cụ CR32 thật là hiệu quả, nhưng với một quy trình khép kín và đảm bảo đến như vậy thì ở đây tôi vẫn có 2 thắc mắc: thứ nhất là tại sao không chỉ đơn giản là split tập tin gốc mà thôi, thứ hai là nếu trung thành với WinRAR thì tại sao vẫn cần "Put recovery record"?
A: Thắc mắc của bạn hoàn toàn chính xác, nhưng giải đáp của tôi cũng sẽ chính xác không kém.
Ở thắc mắc thứ nhất, nếu chỉ đơn giản là split tập tin thì bạn sẽ không loại trừ được khả năng có lỗi bit trong quá trình xử lý của chương trình spliter. Để kiểm tra như trong Bước 3, bạn sẽ phải merge lại rồi tính CRC32 của file kết quả: tăng thêm một lần có khả năng rủi ro mà tiêu tốn tài nguyên hơn là để WinRAR làm việc đó (WinRAR tự tính CRC32 của dữ liệu mà nó xử lý). Tương tự như vậy khi tải về, cho dù bạn đã tải được tất cả các part tốt nhưng chưa chắc bạn sẽ merge lại thành tập tin MKV nguyên thủy.
Còn đối với thắc mắc thứ hai, tôi có thể tự hào tuyên bố rằng tôi làm điều đó vì các bạn - những người sẽ tải về. Bạn sẽ làm gì nếu part bạn vừa tải không khớp mã kiểm tra sau vài lần tính CRC32? Hãy thử vận may của mình bằng chức năng Repair của WinRAR vì nếu thành công thì nó nhanh hơn nhiều so với việc tải lại. Ngoài ra tôi cũng khuyên bạn nên đưa 7zip vào danh mục phần mềm của mình vì trong 1 số trường hợp 7zip có thể vượt qua những lỗi nhỏ của tập tin RAR.
Q: Xin cảm ơn, Vô cùng cảm ơn. Trước khi kết thúc, bạn có thể giới thiệu về những công cụ mà bạn đã sử dụng trong quy trình đó hay không?
A: Không có gì, những công cụ mà tôi sử dụng hoàn toàn bình thường và mọi người đều biết, chỉ riêng có ExactFile chuyên dùng để tính các loại mã kiểm tra thì bạn có thể vào trang web www[dot]exactfile[dot]com để tham khảo.
(Phỏng vấn do ABChen tự thực hiện cho HDVietnam.com)
