파일 시퀀스

이 기사는 어떠한 출처도 인용하지 않는다. 신뢰할 수 있는 출처에 인용문을 추가하여 이 기사를 개선하는 데 도움을 주십시오. 조달되지 않은 자재는 제거될 수 있습니다.출처 : "파일 시퀀스"– 뉴스 · 신문 · 서적 · 학자 · JSTOR (2009년 2월) (이 템플릿메시지 삭제 방법 및 삭제 타이밍에 대해 알아보기)

비컴퓨팅 컨텍스트뿐만 아니라 컴퓨팅에서 파일 시퀀스는 일반적으로 어떤 식으로든 서로 관련이 있는 정렬된 (확실한) 파일 집합입니다.

컴퓨팅에서 파일시퀀스는 어떤 종류의 참조원칙에 따라야 합니다.따라서 같은 시퀀스에 속하는 모든 파일이 서로 로컬로 참조되어야 할 뿐만 아니라 순서관계에 대한 근접성만큼이나 파일시퀀스도 따라야 합니다.명시적 파일시퀀스는 실제로는 파일명이 모두 마지막에 숫자 또는 영숫자 태그로 끝나는 시퀀스입니다(파일 확장자는 제외).

앞서 언급한 참조 위치는 일반적으로 데이터, 메타데이터(파일 이름 또는 마지막 액세스 날짜 등) 또는 해당 파일이 상주하는 스토리지 미디어 내의 물리적 근접성 중 하나에 관련됩니다.후자의 경우 파일 인접성에 대해 말하는 것이 좋습니다(아래 참조).

신분증

모든 GUI 프로그램은 보통 파일 이름과 같은 파일의 메타데이터와 관련된 몇 가지 기준에 따라 파일을 정렬하여 폴더의 내용을 표시합니다.디폴트에서는, 파일명의 영숫자 순서가 기준이 됩니다만, 일부의 operating system은 다른 operating system보다 「간단한」 방법으로 파일명의 순서를 지정합니다.예를 들어 다음과 같습니다.file1.ext이상적으로는 앞에 놓여야 한다file10.extGNOME Files 나 Thunar 와 같이, 영숫자로는 (나중에 더 자세히 설명) 뒤에 나옵니다.파일 형식(또는 확장자)을 기준으로 파일을 정렬하거나 파일 이름 또는 마지막 액세스 날짜별로 파일을 정렬하는 등의 다른 기준이 있습니다.

따라서 파일 시퀀스가 참조의 국소성이 더 강한 경우, 특히 실제 내용과 관련된 경우, 파일 이름의 영숫자 순서도 잘 정렬되도록 함으로써 이 사실을 강조하는 것이 좋습니다.이것은 명시적인 파일시퀀스의 경우입니다.

명시적 파일 시퀀스

명시적 파일 시퀀스는 마지막 부분(확장자 제외)을 제외하고 동일한 파일 이름(내용의 참조 위치를 확인하기 위한 파일 확장자 포함)을 가집니다.확장자는 숫자, 영숫자 또는 순수 알파벳 문자로 이루어진 시퀀스입니다.이러한 시퀀스도 이상적인 위치에 배치되어 있어야 합니다.l은 같은 디렉토리 내에 있습니다.

이 점에서 같은 파일명(확장자 포함)을 공유하는 파일은 파일명 말미의 시퀀스 번호에 의해서만 다를 뿐, 적어도 같은 폴더에 있는 경우는 자동적으로 같은 파일시퀀스에 속합니다.또한 많은 명명규칙의 일부로서, (임의의 숫자 베이스로) 최대 고정 자리수의 파일을 포함하는 번호 색인화된 파일 시퀀스는 파일 이름에 "추적 0"을 사용하여 다음과 같은 작업을 수행합니다.

• 시퀀스 내의 모든 파일이 완전한 파일 이름에서 정확히 동일한 수의 문자를 공유합니다.
• operating system의 GUI와 같이, 스마트하지 않은 영숫자 순서는, 순서내에서 잘못해 허가되지 않습니다.

후자의 요점을 더 잘 설명하기 위해서 엄밀히 말하면,file1.ext(시퀀스 중 첫 번째 파일)은 영숫자 뒤에 있습니다. file100.ext사실 100번째에요.첫 번째 파일 이름 변경file001.ext두 개의 끝 0이 있으면 이 문제는 보편적으로 해결됩니다.

명시적 파일시퀀스의 예는 다음과 같습니다.file00000.ext,file00001.ext,file00002.ext${\displaystyle ,}$ .${\displaystyle }$.$${ $displaystyle ...$ $\},$file02979.ext(후행 제로 5개) 및 파일 256개의 16진수 순서가 있는 다른 것tag_00.ext,tag_01.ext${\displaystyle ,}$ .${\displaystyle }$.$${ $displaystyle ...$ $\},$tag_09.ext,tag_0A.ext, ...,tag_0F.ext,tag_10.ext, ...,tag_0F.ext, ...,tag_FF.ext(0의 후행은 1개뿐입니다).

소프트웨어 및 프로그래밍 규칙은 보통 파일 시퀀스를 단일 가상 파일 개체로 나타냅니다.이 오브젝트의 이름은 파일 이름 내의 시퀀스 번호의 위치와 포맷을 나타내기 위해 C와 같은 형식 문자열 표기로 포괄적으로 쓰여집니다.위의 두 가지 예에서는 다음과 같습니다.filename%05d.ext그리고.tag_%02H.ext각각, 반면 전자의 경우, 0 뒤에 오는 것이 없는 동일한 규약은filename%5d.ext단, 이러한 표기법은 일반적으로 운영체제 및 명령줄 인터페이스 수준에서는 유효하지 않습니다.%' 문자는 유효한 정규 표현도 아니고 보편적으로 유효한 파일 이름 문자도 아닙니다.이 표기는 명시적인 파일 시퀀스 전체를 나타내는 가상 파일 같은 것에 대한 자리 표시자일 뿐입니다.

오디오/비디오 포스트 프로덕션 업계(아래 참조)에서는 일반적인 단일 파일 시스템 개체로 명시적인 파일 시퀀스를 인정하는 주목할 만한 소프트웨어 패키지가 오토데스크, Quantel, daVinci, DVS 및 Adobe After Effects의 제품 중 있습니다.

파일 산란

대용량 저장 장치 내에 위치한 파일 시퀀스는 다음과 같은 경우 연속이라고 합니다.

• 시퀀스 내의 모든 파일은 fragment화되지 않습니다.즉, 각 파일은 연속된1개의 스토리지 공간(하나 또는 여러 개의 연속된 익스텐트)에 저장됩니다.
• 연속되는 파일은 스토리지 공간의 인접 부분을 차지합니다(확장자이지만 파일 순서와 일관됩니다).

파일 인접성은 파일 시퀀스 자체(또는 메타데이터)보다 전체 시퀀스를 호스팅하는 스토리지 미디어와 관련이 있기 때문에 참조 위치보다 파일 시퀀스에 더 실용적인 요구 사항입니다.동시에 대용량 스토리지 자체의 물리적 및 기술적 세부사항과 관련이 없기 때문에 "고급" 기능입니다. 특히 스토리지 장치의 아키텍처와 실제 파일 시스템 구조에 따라 파일 인접성이 다른 방식으로 실현됩니다."낮은 수준"에서는 연속된 시퀀스의 각 파일을 파일 시스템에서 실제로 인터리빙하는 데 필요한 예약된 영역 또는 특수 메타데이터에도 불구하고 연속된 블록에 배치해야 합니다.

파일 정합성은 대부분의 실제 애플리케이션에서 운영 체제 또는 사용자 수준에서 "보이지 않는" 것입니다. 왜냐하면 시퀀스의 모든 파일은 스토리지 장치 상의 물리적 위치에 관계없이 항상 동일한 방식으로 애플리케이션에서 사용할 수 있기 때문입니다(운영 체제가 파일 시스템 내부에 더 높은 수준의 서비스를 은폐하기 때문입니다).실제로 파일 인접성은 시퀀스를 가능한 한 짧은 시간에 읽거나 써야 하는 경우 I/O 성능과 관련이 있을 수 있습니다.(아래 광디스크 굽기 등) 일부 컨텍스트에서는 파일 시퀀스의 데이터에 파일 시퀀스 자체와 같은 순서로 액세스해야 하며, 다른 컨텍스트에서는 시퀀스에 대한 "랜덤" 액세스가 필요할 수 있습니다.어느 경우든 대부분의 프로페셔널파일 시스템은 비연속 파일보다 연속 파일에 대한 액세스 전략이 빠릅니다.데이터 사전 할당은 쓰기 액세스에 매우 중요한 반면, 버스트 읽기 속도는 연속된 데이터에 대해서만 달성할 수 있습니다.

파일 시퀀스가 연속되지 않으면 파일이 저장 장치의 스파스 위치에 저장되기 때문에 분산된다고 합니다.파일 산란이란 파일시퀀스를 연속되지 않은(또는 연속되지 않은) 상태로 할당(또는 재할당)하는 프로세스입니다.이는 파일 조각화와도 관련이 있는 경우가 많습니다.여기서 각 파일은 연속되지 않은 여러 블록에 저장됩니다.전자의 원인이 되는 메커니즘은 일반적으로 후자의 경우에도 공통적인 원인이 됩니다.(처음부터) 파일을 할당하거나 (이미 저장된 데이터에 대해) 동일한 순서로 이동함으로써 파일 산란을 줄이는 행위를 (파일) 파일 기술이라고 합니다.몇 가지 조각 모음 전략과 전용 소프트웨어는 단일 파일 조각 모음과 파일 시퀀스를 모두 수행할 수 있습니다.

멀티미디어 파일 시퀀스

명시적 파일 시퀀스가 특히 중요한 컨텍스트는 여러 가지가 있습니다. 즉, 증분 백업, 정기 로그 및 시간순 참조를 통해 캡처 또는 생성된 멀티미디어 파일입니다.후자의 경우 소프트웨어와 최종 사용자 모두에게 저장된 콘텐츠의 중요도를 판별할 수 있는 방법을 제공하기 위해 명시적인 파일 번호가 매우 중요합니다.예를 들어, 디지털 카메라와 같은 디바이스는, 모든 화상 파일을 같은 폴더에 보존합니다(최대 파일 번호 용량에 도달할 때까지, 또는 심야 촬영이나 디바이스 스위칭등의 새로운 이벤트가 발생할 때까지).촬영시에 촬영할 때마다 파일명을 선택하는 것은 매우 비현실적입니다.따라서 카메라 펌웨어/소프트웨어는 시퀀스 번호로 완벽하게 식별할 수 있는 것을 선택합니다.다른 메타데이터(일반적으로 특수한 PC 소프트웨어)를 사용하여 나중에 멀티미디어 콘텐츠를 식별하여 필요에 따라 재구성할 수 있습니다.

Digital Intermediate의 예

명시적인 파일 시퀀스와 그 인접성이 중요한 대표적인 예는 영화 및 비디오 산업의 디지털 중간(DI) 워크플로우입니다.이러한 상황에서 비디오 데이터는 최고 품질을 유지하고 시각화할 준비가 되어 있어야 합니다(보통 더 좋지는 않더라도 실시간).통상, 비디오 데이터는 디지털 비디오 카메라 또는 동영상 필름 스캐너로부터 취득해, 파일 시퀀스에 보존됩니다(일반 포토 카메라와 같음).최소한 편집, 적합, 색보정을 포함한 몇개의 스텝으로 후작성이 필요합니다.여기에는 다음이 필요합니다.

• 압축되지 않은 데이터는 대부분의 최종 제품에서 일반적으로 발생하는 손실 압축으로 인해 허용할 수 없는 품질 손실이 발생하기 때문입니다.
• 압축 해제 시간이 하드웨어 및 소프트웨어에 의한 재생/시각화 성능을 저하시킬 수 있기 때문에 압축되지 않은 데이터입니다.
• 파일 단위의 프레임 데이터 관리.일반적인 포스트 프로덕션 조작은 가장 짧은 시크 타임을 의미하기 때문에 특정(키) 프레임에 대한 "빠른 포워딩" 또는 "다시 바인딩"은 거대하고 단편화된 비디오 파일 내가 아니라 파일 시스템 수준에서 수행될 경우 훨씬 더 빨라집니다. 그러면 모든 프레임이 하나의 파일에 여전히 디지털 그림으로 저장됩니다.
• 명확한 이유로 프레임의 순서를 지정합니다.이 순서는 모든 파일을 명시적인 파일 번호 부여로 그룹화하는 것이 가장 좋습니다.
• 파일 인접성: 많은 파일 시스템 아키텍처가 스토리지의 인접 영역에 데이터를 전송할 때 더 높은 I/O 속도를 사용하는 반면 랜덤 할당은 실시간 또는 더 나은 로드 성능을 방해할 수 있습니다.

DI 프로젝트의 단일 프레임은 현재 9MB에서 48MB 사이즈의 크기(해상도나 색상에 따라 다름)인 반면, 비디오 리프레시 레이트는 일반적으로 초당 24 또는 25프레임(빠르지 않은 경우)입니다.따라서 이러한 콘텐츠를 실시간으로 재생하기 위해 필요한 모든 스토리지는 220MB/s에서 1.2까지의 총 스루풋이 필요합니다.각각 GB/s이러한 수치로 인해 위의 모든 요구사항(특히 오늘날 스토리지 성능을 감안할 때 파일 인접성)이 엄격히 의무화됩니다.

외부 링크

• PySeq PySeq는 숫자 시퀀스 인덱스를 포함하는 명명 규칙을 따르는 항목 그룹(예: fileA.001.png, fileA.003.png...)을 찾아 전체 시퀀스(예: file-3NG)를 나타내는 압축 시퀀스 문자열로 직렬화하는 오픈 소스 파이썬 모듈입니다.
• checkfileseq checkfileseq는 오픈소스 python 스크립트(CLI를 통해 사용 가능)로, 파일시퀀스에서 누락된 파일을 재귀적으로 스캔하여 완료 시 보고서를 인쇄합니다.다양한 파일 이름 패턴을 지원하며 추가 패턴 로직을 얻기 위해 맞춤화할 수 있습니다.