영상 파일을 종류별로 나누는 처리를 확장자와 크기 기준으로 만들었다. 대부분 맞았지만 틀린 것이 눈에 띄게 섞여 있었다.
Table of contents
Open Table of contents
확장자와 크기가 못 가른 것
화질이 낮은 30분짜리는 크기가 작아서 짧은 것으로 들어갔다. 반대로 고화질 3분짜리는 크기가 커서 본편으로 들어갔다.
크기는 길이에 대해 아무것도 말해 주지 않는다. 화질과 코덱이 같은 길이에서도 크기를 몇 배씩 벌리기 때문이다.
내용을 읽어야 갈렸다
분석 도구로 파일을 열어 보니 길이와 비트레이트와 해상도가 나왔다. 그중 길이를 기준으로 나누니 어긋나던 것들이 제자리로 갔다.
확장자와 크기는 파일의 형태이고 길이와 해상도는 파일의 내용이다. 형태로 분류하면 내용이 다른 것이 같은 자리에 들어간다.
읽는 비용과 사전 거르기
문제는 내용을 보려면 파일을 실제로 열어야 한다는 점이었다. 목록만 보면 되는 크기 확인과 달리 파일당 백몇십 밀리초가 들었고 4만 개면 두 시간이었다.
그래서 전부 분석하지 않고 명백한 것을 형태로 먼저 걸렀다. 영상 확장자가 아니면 분석하지 않고 1메가 미만이면 썸네일로 넘겨서 나머지만 분석하니 6분으로 내려갔다.
분석 결과는 저장해서 같은 파일을 다시 읽지 않게 했다. 경로와 수정 시각과 크기를 키로 잡았으므로 파일이 바뀌면 자연히 다시 분석된다.
실패한 분석의 자리
깨진 파일과 0바이트 파일과 지원하지 않는 코덱에서 분석이 실패하거나 일부 정보만 나왔다. 이런 것은 형태로 짐작해서 채워 넣지 않고 미상으로 두고 따로 셌다.
세어 보니 대부분이 깨진 파일이었고 그 자체가 봐야 할 문제였다. 짐작해서 넣었으면 분류는 채워졌겠지만 깨진 파일이 있다는 사실은 드러나지 않았을 것이다.
표본이 드러낸 경계 구간
전체를 믿기 전에 쉰 개를 무작위로 뽑아 눈으로 대조했다. 셋이 틀렸는데 전부 기준선 바로 아래위에 있는 것이었다.
기준을 물으니 십 분 안팎은 상관없다는 답이 왔다. 그래서 기준을 정확히 맞추는 대신 애매한 구간을 사람이 보는 자리로 따로 뒀다.
저장할 때는 분류 결과만 넣지 않고 길이와 해상도와 비트레이트도 같이 넣었다. 실제로 기준이 두 번 바뀌었는데 원래 값이 있어서 다시 분석하지 않고 조회 한 번으로 다시 나눌 수 있었다.
정리
- 형태로 분류하면 내용이 다른 것이 같은 자리에 들어간다
- 크기는 길이에 대해 아무것도 말해 주지 않는다
- 내용을 보려면 파일을 열어야 하므로 읽는 비용을 먼저 잰다
- 명백한 것은 형태로 거르고 나머지만 분석한다
- 분석 결과를 저장하되 키에 수정 시각과 크기를 넣는다
- 실패한 것은 짐작해서 넣지 않고 따로 세면 문제가 드러난다
- 표본을 눈으로 대조하면 경계 구간이 보인다
- 판단 결과만 저장하면 기준이 바뀔 때 처음부터 다시 해야 한다