DE60035455T2

DE60035455T2 - Halbleiterspeicherkarte, Wiedergabegerät, Aufnahmegerät, Wiedergabeverfahren, Aufnahmeverfahren und vom Computer lesbarer Aufzeichnungsträger

Info

Publication number: DE60035455T2
Application number: DE60035455T
Authority: DE
Inventors: Teruto Moriguchi-shi Hirota; Kenji Katano-shi TAGAWA; Hideki 3217 Studio City Matsushima; Tomokazu Toyonaka-shi Osaka-fu Ishikawa; Shinji Neyagawa-shi Inoue; Masayuki Arcadia Kozuka
Original assignee: Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp
Priority date: 1999-05-28
Filing date: 2000-05-26
Publication date: 2007-11-08
Anticipated expiration: 2020-05-27
Also published as: JP2001249695A; CN1187756C; CN1318196A; BR0006882A; BR0006882B1; EP1056092A1; US7596698B2; DE60035455D1; CA2338634A1; ID27746A; US8156347B2; US20050192686A1; JP4150278B2; WO2000074059A1; MY125354A; JP2004030586A; CA2338634C; US6865431B1; US20100064145A1; JP3425119B2

Description

Die Erfindung betrifft eine Halbleiterspeicherkarte, die Audiodaten und Steuerdaten speichert, sowie eine Abspielvorrichtung, eine Aufzeichnungsvorrichtung, ein Abspielverfahren, ein Aufzeichnungsverfahren und ein computerlesbares Aufzeichnungsmedium im Zusammenhang mit der Halbleiterspeicherkarte. Die Erfindung betrifft insbesondere die verbesserte Speicherung von Verwaltungsinformationen und Audiodaten, die von einem Inhaltsverteilungsdienst, so beispielsweise von einem elektronischen Musikverteilungsdienst, als Inhalte verteilt werden.
In den vergangenen Jahren wurde schrittweise diejenige Hardwareinfrastruktur eingeführt, die für die elektronische Verteilung von Musik notwendig ist. Dies trägt das Potential großer Veränderungen für die Musikindustrie in sich, wo Erzeugnisse bislang üblicherweise als Softwarepakete unter Verwendung von Medien wie Compact Discs (CDs) und Kassettenbändern verteilt worden sind.
Elektronische Musikinhalte (beispielsweise Lieder und Alben) können daher dadurch an Verbraucher verteilt werden, dass der Personalcomputer des Verbrauchers in die Lage versetzt wird, Inhalte von einem Servercomputer herunterzuladen, der von einer Plattenfirma betrieben wird. Damit sich der Anwender die heruntergeladene digitale Musik auf einem tragbaren Abspielgerät anhören kann, muss er die Musikdaten auf einem tragbaren Aufzeichnungsmedium speichern. Gegenwärtig sind die am besten geeigneten Medien zum Speichern von elektronisch verteilten Musikdaten Halbleiterspeicherkarten.
Als Beispiele hierfür sind bislang Flash-ATA-Karten und COMPACT-FLASH-Karten erhältlich. Derartige Halbleiterspeicherkarten enthalten eine Halbleitervorrichtung, die Flash-Speicher genannt wird (EEPROM – Electrically Erasable Programmable Read-Only Memory, elektrisch lesbarer programmierbarer Nurlesespeicher). Der Flash-Speicher kann Daten mit sehr viel höheren Geschwindigkeiten als MDs (MiniDisc) oder CD-Rs (CompactDiscs-Recordable) lesen und schreiben. Dies bedingt, dass digitale Musik ungeachtet ihrer großen Datenmengen innerhalb kurzer Zeitspannen übertragen werden kann.
Der größte Nachteil bei Halbleiterspeicherkarten ist das Risiko, dass Anwender in die Lage versetzt werden, illegale Kopien von urheberrechtlich geschützter Musik zu erstellen, die von einem elektronischen Musikverteilungsdienst heruntergeladen worden ist. Da Halbleiterspeicherkarten das Schreiben von Daten mit höheren Geschwindigkeiten als CD-Rs oder MDs ermöglichen, ist davon auszugehen, dass das Kopieren bei derartigen Speicherkarten ein schwerwiegenderes Problem darstellt. Um die möglichen Gefahren im Zusammenhang mit einer Verletzung von Urheberrechten zu beseitigen, muss digitale Musik unter Verwendung eines sicheren Verschlüsselungsverfahrens verschlüsselt werden, bevor sie auf einer Halbleiterspeicherkarte gespeichert wird.
Ein Speicherverfahren, das dem Umstand, ein nicht autorisiertes Kopieren zu verhindern, Rechnung trägt, ist das Titelspeicherverfahren (title storage method), das beim DVD-Audiostandard zum Einsatz kommt. Bei einem Beispiel für dieses Verfahren enthält ein „Titel" (title), der einem herkömmlichen Musikalbum entspricht, eine Vielzahl von „Inhalten" (contents), die den Spuren (tracks) auf dem Album entsprechen. Die Inhalte, die einen Titel bilden, werden unter Verwendung eines Verschlüsselungsschlüssels (encryption key) verschlüsselt, der „Titelschlüssel" (title key) genannt wird und vom Plattenhersteller vor der Aufzeichnung auf einer DVD-Audiodisk gewählt wird. Dieser Titelschlüssel wird unter Verwendung eines Verschlüsselungsschlüssels (der üblicherweise „Diskschlüssel" (disc key) genannt wird) verschlüsselt, der wiederum für jede DVD-Audiodisk eindeutig ist und in einem Sektorheaderbereich der DVD-Audiodisk gespeichert wird. Der Diskschlüssel selbst wird unter Verwendung eines Verschlüsselungsschlüssels (der üblicherweise „Masterschlüssel" (master key) genannt wird) verschlüsselt, der wiederum von den Herstellern von Inhaltsdecodiervorrichtungen im Einlaufbereich (lead-in reagion) der DVD-Audiodisk aufgezeichnet wird. Der Sektorheaderbereich und der Einlaufbereich sind für normale Anwender nicht zugänglich, wodurch es für Anwender außerordentlich schwierig wird, den auf einer DVD-Audiodisk aufgezeichneten Titelschlüssel zu ermitteln.
Im Vergleich zu magnetischen und optischen Speichermedien weisen Halbleiterspeicherkarten eine begrenzte Speicherkapazität auf, weshalb es üblicherweise notwendig ist, digitale Musik beim Speichern auf einer Halbleiterspeicherkarte mit einem höheren Kompressionsverhältnis zu komprimieren. Ein Verschlüsselungsverfahren zum Erreichen eines ausreichend hohen Kompressionsverhältnisses für digitale Musik ist MPEG2-AAC (Motion Pictures Experts Group 2 – Advanced Audio Coding, Expertengruppe 2 für bewegte Bilder – weiterentwickelte Audiocodierung). Eine charakteristische Eigenschaft der MPEG2-AAC-Kompression besteht darin, dass sie sich das beschränkte menschliche Hörvermögen zunutze macht und dadurch die Bitlänge der jedem Audioframe zugewiesenen Daten ändert, wobei ein Audioframe die kleinste Abspieleinheit ist, die etwa 20 ms dauert. Daten mit größeren Bitlängen werden Audioframes zugewiesen, die viele Frequenzen innerhalb des Bereiches des menschlichen Hörvermögens aufweisen, wohingegen Daten mit kleineren Bitlängen Audioframes mit weniger derartigen Tönen oder Frequenzen außerhalb des Bereiches des menschlichen Hörvermögens zugewiesen werden.
Da die Datenmenge, die jedem Audioframe bei MPEG2-AAC zugewiesen wird, von der Anzahl der hörbaren Frequenzen in dem Frame abhängt (mit anderen Worten, da sich MPEG2-AAC einer Codierung mit veränderlicher Bitrate (VBR variable bitrate, veränderliche Bitrate) bedient, erhält man auch bei hohen Kompressionsraten qualitativ hochwertige Audioinhalte. Die Audioinhalte sind zur Verteilung über ein öffentliches Netzwerk und zur Speicherung auf Halbleiterspeicherkarten, die nur eine begrenzte Speicherkapazität aufweisen, geeignet.
Die Druckschrift US-A-5,727,061 beschreibt ein Autorisierungssystem und insbesondere ein Mehrkomponentensystem, das einzigartige Erkennungs- und Verarbeitungsverfahren zur Verifizierung von Parteiidentitäten und Gewährleistung der Sicherheit implementiert. Das System enthält eine Anwenderverarbeitungsvorrichtung, eine Speichervorrichtung und eine Providervorrichtung. Die Speichervorrichtung speichert providerspezifische Anwendungssoftware unter Verwendung spezifischer Daten und ein Dateiverwaltungsprogramm. Unter Leitung des Dateiverwaltungsprogramms führt die Verarbeitungsvorrichtung ein Erkennungsverfahren durch, bei dem bestimmt wird, ob die Verarbeitungsvorrichtung und die Speichervorrichtung autorisiert sind, miteinander zu arbeiten. Hierdurch wird es möglich, die Speichervorrichtung in die Lage zu versetzen, nur mit einer spezifischen Anwendervorrichtung zusammenzuarbeiten, was Betrugsmöglichkeiten verringert. Sobald bestimmt worden ist, dass die Verarbeitungsvorrichtung und die Speichervorrichtung für einen miteinander erfolgenden Austausch autorisiert sind, führt die Verarbeitungsvorrichtung die bereitgestellte providerspezifische Anwendungssoftware aus, um Informationen mit der Providervorrichtung auszutauschen. Hierdurch stellt das System einen hochgradig sicheren Mechanismus zum Übertragen von Informationen von einer Partei an eine andere bereit.
Werden Inhalte nach Maßgabe herkömmlicher Verfahren gespeichert, so wird das Decodieren des Titelschlüssels zum Verschlüsseln der Musikinhalte verwendet, was einen Anwender in die Lage versetzt, sämtliche Musikinhalte, die auf einem Aufzeichnungsmedium aufgezeichnet sind, zu entschlüsseln. Dies führt zu einem ersten Problem dahingehend, dass ein einzelner Titelschlüssel offen liegt, wodurch es für Anwender einfach wird, sämtliche auf einer Halbleiterspeicherkarte gespeicherten Spuren (tracks) zu entschlüsseln.
Eingedenk dessen, dass die Titelschlüssel nur selten offen liegen, führt ein derartiges Offenliegen zu großen Verlusten für den Urheberrechtsinhaber. Mit Blick auf die großen Fortschritte bei der Arbeitsleistung von Homecomputern in den vergangenen Jahren wird es zunehmend schwierig, die Aussage zu machen, dass ein Titelschlüssel, der zur Verschlüsselung von digitaler Musik verwendet wird, vor einer Decodierung absolut sicher ist. Hierdurch entsteht die Notwendigkeit einer Datenzusammensetzung, bei der der Schaden für Urheberrechtsinhaber bei Offenliegen eines Titelschlüssels minimiert wird.
Da urheberrechtlicher Schutz für digitale Musik, die über eine elektronische Musikverteilung verteilt werden soll, notwendig ist, wird diese Musik üblicherweise in verschlüsselter Form verteilt. Eine Verschlüsselung ist darüber hinaus für digitale Musik erforderlich, die auf einer Halbleiterspeicherkarte gespeichert wird. Dies führt jedoch zu dem zweiten Problem, dass ein Anwender, der beim Erwerb der digitalen Musik den entsprechenden Preis entrichtet hat, nicht in der Lage ist, die Musik frei zu bearbeiten, wenn diese verschlüsselt auf der Halbleiterspeicherkarte gespeichert ist. Sind die Musikinhalte in verschlüsselter Form gespeichert, so ist es für den Anwender sehr schwierig, die Reihenfolge der Spuren (tracks) zu ändern oder Spuren (tracks) teilweise zu löschen. Eingedenk dessen, dass der Anwender einen entsprechenden Preis entrichtet hat, ist nicht wünschenswert, seine/ihre Möglichkeiten, die Musikinhalte zu bearbeiten, derart einzuschränken.
Minidiskaufzeichnungsgeräte (MD-Aufzeichnungsgeräte), die zur Aufzeichnung von Musik auf dieselbe Weise wie eine Halbleiterspeicherkarte verwendet werden können, bieten eine Vielzahl von Spurbearbeitungsfunktionen, da sie eine Inhaltstabelle TOC (table of contents) aufweisen. Zu diesen Funktionen gehören das Neuanordnen der Abspielreihenfolge der Spuren, das Unterteilen von Spuren und das Kombinieren von Spuren zu einer einzigen Spur. Sind halbleiterspeicherkartenbasierte Aufzeichnungsgeräte nicht in der Lage, dieselben Funktionen wie herkömmliche MD-Aufzeichnungsgeräte bereitzustellen, so ist davon auszugehen, dass Verbraucher die halbleiterspeicherkartenbasier ten Abspielgeräte den MD-Abspielgeräten gegenüber als minderwertig betrachten, was dem Marktpotential von halbleiterspeicherkartenbasierten Erzeugnissen schadet.
Zur Bereitstellung von Spezialabspielfunktionen für digitale Musik, die einer VBR-Codierung unterworfen worden sind, wie dies bei MPEG2-AAC der Fall ist, müssen Abspielvorrichtungen mit Speichern großer Speicherkapazität ausgestattet sein. Dies erhöht die Herstellungskosten derartiger Vorrichtungen und führt zu einem dritten Problem im Zusammenhang mit dem Stand der Technik.
Die von den MD- oder CD-Abspielgeräten bereitgestellten Spezialabspielfunktionen umfassen die Möglichkeit, das Abspielen ab einer beliebigen Spur auf einer Disk (bei Spezifizierung der Abspielposition) zu beginnen, eine Musiksuchfunktion, die intermittierende Musikfetzen abspielt, um Anwender in die Lage zu versetzen, vorwärts und rückwärts mit hoher Geschwindigkeit durch die Spuren zu springen, sowie eine Zeitsuchfunktion, die den Anwendern ermöglicht, den Abspielanfang auf eine Position einzustellen, die als Zeit eingegeben wird, die ab dem Anfang der Disk gemessen wird. Um den Markt, den derzeit MD- oder CD-Abspielgeräte beherrschen, zu erobern, ist es für Abspielvorrichtungen mit Halbleiterspeicherkarten wesentlich, dieselben Spezialabspielfunktionen wie MD-Abspielgeräte zu bieten. Werden Musikinhalte einer Codierung mit konstanter Bitrate (CBR constant bitrate, konstante Bitrate) unterzogen, so kann das Abspielen ab einer Position, die unter Verwendung eines Zeitcodes (beispielsweise eines Punktes, der ein oder zwei Minuten vom Anfang einer Spur entfernt liegt) einfach dadurch ausgelöst werden, dass auf eine Adresse verwiesen wird, die um ein ganzzahliges Vielfaches der Datengröße der Einheitsabspielzeit versetzt ist. Sind Musikinhalte jedoch unter Verwendung eines VBR-Verfahrens, so beispielsweise von MPEG2-AAC, codiert, so sind die Positionen entsprechend einer oder zwei Minuten vor der aktuellen Position selten um ein ganzzahliges Vielfaches der Datengröße der Einheitsabspielzeit versetzt. Daher benötigt ein Abspielgerät keinen Verweis auf eine vorab erzeugte Zeitsuchtabelle zur Darlegung, welche Adressen den eine oder zwei Minuten weiter vorne befindlichen Punkten entsprechen.
Während eine Zeitsuchtabelle für eine kurze Spur keine große Anzahl von Abspielpositionen umfassen muss, kann dies für Zeitsuchtabellen von langen Spuren nicht gelten, weshalb die Zeitsuchtabellen von langen Spuren sehr groß sind. Zur Bereitstellung von Spezialabspielfunktionen benötigt eine Abspielvorrichtung Zugriff auf die Zeitsuchtabelle, die sie zunächst in ihren Speicher laden muss. Da derartige lange Spuren große Zeit suchtabellen aufweisen, bedeutet dies, dass eine Abspielvorrichtung mit einem großen Speicher zum Speichern der Zeitsuchtabelle ausgestattet werden muss. Dies erhöht die Herstellungskosten der Abspielvorrichtungen weiter.
Zusammenfassung der Erfindung
Eine erste Aufgabe der vorliegenden Erfindung besteht darin, eine Halbleiterspeicherkarte bereitzustellen, die die Urheberrechte von Musikinhalten, die darauf gespeichert sind, schützt, während sie gleichzeitig Anwendern das Bearbeiten der Musikinhalte ermöglicht.
Eine zweite Aufgabe der vorliegenden Erfindung besteht darin, eine Musikabspielvorrichtung bereitzustellen, die Spezialabspielfunktionen, so beispielsweise die Vorwärts- und Rückwärtssuche nach Musikinhalten, die auf der Halbleiterspeicherkarte aufgezeichnet sind, bietet, ohne dass hierfür ein Speicher großer Kapazität von Nöten wäre.
Die erste Aufgabe der vorliegenden Erfindung kann durch eine Halbleiterspeicherkarte gelöst werden, die wenigstens eine Audiospur (audio track) speichert, umfassend: einen geschützten Bereich, auf den eine mit der Halbleiterspeicherkarte verbundene Vorrichtung nur dann zugreifen kann, wenn sich die Vorrichtung als authentisch erwiesen hat, wobei der geschützte Bereich eine Verschlüsselungsschlüsselsequenz speichert, die sich aus einer Vielzahl von Verschlüsselungsschlüsseln zusammensetzt, die in einer vorgegebenen Reihenfolge angeordnet sind; und einen ungeschützten Bereich, auf den eine mit der Halbleiterspeicherkarte verbundene Vorrichtung zugreifen kann, wobei der ungeschützte Bereich wenigstens eine Audiospur und Verwaltungsinformationen speichert, die wenigstens eine Audiospur eine Vielzahl von verschlüsselten Audioobjekten enthält und die Verwaltungsinformationen zeigen, welcher Verschlüsselungsschlüssel aus der Vielzahl von Verschlüsselungsschlüsseln jedem in dem ungeschützten Bereich gespeicherten Audioobjekt entspricht.
Eingedenk der beschriebenen Zusammensetzung kann eine Vielzahl von Audioobjekten unter Verwendung einer Vielzahl von Verschlüsselungsschlüsseln verschlüsselt werden, sodass für den Fall, dass der zur Verschlüsselung eines bestimmten Audioobjektes verwendete Verschlüsselungsschlüssel decodiert werden sollte und offen liegt, diese Decodierung lediglich zulässt, dass dieses bestimmte Audioobjekt entschlüsselt wird, während keinerlei Auswirkungen auf andere Audioobjekte gegeben sind. Dies bedeutet, dass bei der vorliegenden Halbleiterspeicherkarte der durch Offenlegen von einem der Verschlüsselungsschlüssel verursachte Schaden minimiert wird.
Hierbei kann jede Audiospur des Weiteren enthalten: (1) Attributinformationen und (2) Verknüpfungsinformationen für jedes in der Audiospur enthaltene Audioobjekt, wobei die Attributinformationen einen Typ von einem Typ (a), einem Typ (b), einem Typ (c) und einem Typ (d) für jedes Audioobjekt zeigen, der Typ (a) die gesamte Audio-Spur, der Typ (b) ein erster Teil einer Audiospur, der Typ (c) ein Mittelteil einer Audiospur und der Typ (d) ein Endteil einer Audiospur ist und die Verknüpfungsinformationen für jedes Audioobjekt, das zu dem Typ (b) oder dem Typ (c) gehört, zeigen, welches Objekt auf das Audioobjekt folgt.
Durch die Verwendung der beschriebenen Zusammensetzung ergeben sich die nachfolgend beschriebenen Wirkungen. Die Attributinformationen zeigen, wie die verschlüsselten Audioobjekte die Audiospuren bilden, sodass dann, wenn zwei Audioobjekte als zwei getrennte Audiospuren verwaltet werden, diese Spuren einfach dadurch zu einer einzelnen Spur kombiniert werden können, dass die Attributinformationen zur Darlegung, dass die Audioobjekte dem Anfang und Ende einer Spur entsprechen, geändert werden. Da die Audiospuren durch Ändern der Attributinformationen kombiniert werden können, können Spuren mit höherer Geschwindigkeit kombiniert werden, ohne dass die Verschlüsselung der Audiospuren entfernt werden müsste.
Hierbei kann die Vielzahl von Audioobjekten enthalten: wenigstens ein Audioobjekt, das nur gültige Daten enthält, die abgespielt werden müssen; und wenigstens ein Audioobjekt, das (1) gültige Daten und (2) ungültige Daten enthält, die sich wenigstens vor oder nach den gültigen Daten befinden, wobei die ungültigen Daten nicht abgespielt werden müssen, jede Audiospur des Weiteren Blockinformationen für jedes Audioobjekt in der Audiospur enthält und die Blockinformationen enthalten: einen Offset, der von der Speicherposition des entsprechenden Audioobjektes gemäß Angabe in den Verwaltungsinformationen gemessen wird; und Längeninformationen, die eine Länge der gültigen Daten angeben, die ab einer durch den Offset angegebenen Position anfangen, wobei die Attributinformationen für ein Audioobjekt zeigen, ob die durch den Offset und die Längeninformationen angegebenen Daten (a) einer gesamten Audiospur, (b) einem ersten Teil einer Audiospur, (c) einem Mittelteil einer Audiospur oder (d) einem Endteil einer Audiospur entsprechen.
Sind gültige Daten am Anfang eines Audioframes vorhanden, so können die Länge dieser ungültigen Daten und die Länge der gültigen Daten in dem Audioframe in den Blockinformationen eingestellt werden. Zeichnet der Anwender eine Radiosendung auf, bei der der Moderator in den Anfangsteil eines Liedes hineinspricht, so kann als Ergebnis ein geeigneter Datenoffset in den Blockinformationen eingestellt werden, durch den das Lied ohne den Einleitungsteil abgespielt wird, der die Stimme des Moderators enthält. Derartige Bearbeitungsfunktionen können einfach dadurch verwirklicht werden, dass in den Blockinformationen angegeben wird, welche Daten nicht abgespielt werden sollen, und werden mit den Audioobjekten in deren verschlüsseltem Zustand vorgenommen. Dies führt dazu, dass Spuren mit hoher Geschwindigkeit bearbeitet werden können.
Die zweite Aufgabe der vorliegenden Erfindung kann durch eine Aufzeichnungsvorrichtung gemäß Definition in Anspruch 7 gelöst werden.
Ist ein Audiostream für ein Musikalbum bestimmt, das eine lange Spur enthält, so wird die lange Spur in eine Vielzahl von Daten unterteilt, um sicherzustellen, dass die Anzahl der Elemente bzw. Stücke von Eintragsinformationen für eine einzelne Datei eine vorgegebene Zahl nicht übersteigt. Das Begrenzen der Anzahl von Stücken bzw. Elementen der Eintragsinformationen in einer Datei verringert die Größe der Verwaltungsinformationen der Datei. Die Verwaltungsinformationen werden von einer Abspielvorrichtung gemäß Definition in Anspruch 6 verwendet. Liest eine Abspielvorrichtung eine Datei und beginnt mit dem Abspielen des in der Datei enthaltenen Audioobjektes, so liest die Abspielvorrichtung die Verwaltungsinformationen für die Datei und speichert diese in einem internen Speicher. Die Verwaltungsinformationen müssen in dem Speicher vorgehalten werden, solange das Abspielen des Audioobjektes andauert. Endet das Abspielen des Audioobjektes, so wird das nachfolgende Audioobjekt gelesen. Beginnt das Abspielen des nachfolgenden Audioobjektes, so werden die entsprechenden Verwaltungsinformationen gelesen und derart in den internen Speicher der Abspielvorrichtung geschrieben, dass sie die bislang gespeicherten Verwaltungsinformationen überschreiben.
Die Abspielvorrichtung führt daher wiederholt einen Vorgang aus, bei dem nur die Verwaltungsinformationen für das gerade abgespielte Audioobjekt in ihren internen Speicher geladen werden. Dies versetzt Abspielvorrichtungen mit begrenzter Speicherkapazität in die Lage, Spezialabspielfunktionen, so beispielsweise die Vorwärts- und Rückwärtssuche, zu bieten.
Die Zuweisung der Vielzahl von Audioobjekten an die Audiospuren und die beim Abspielenden der Audiospuren zu verwendende Reihenfolge werden von den Verwaltungsinformationen bestimmt, sodass Spuren einfach dadurch frei bearbeitet werden können, dass die Verwaltungsinformationen aktualisiert werden.
Kurzbeschreibung der Zeichnung
Diese und weitere Aufgaben, Vorteile und Merkmale der Erfindung erschließen sich aus der nachfolgenden Beschreibung derselben in Verbindung mit der begleitenden Zeichnung, die spezifische Ausführungsbeispiele der Erfindung darstellt. Die Zeichnung setzt sich wie folgt zusammen.
1 zeigt das Aussehen einer Flashspeicherkarte 31 bei einer Betrachtung von oben.
2 zeigt das Aussehen der Flashspeicherkarte 31 bei einer Betrachtung. von unten.
3 zeigt die hierarchische Zusammensetzung der Flashspeicherkarte 31 in den Ausführungsbeispielen.
4A zeigt den Spezialbereich, den Authentisierungsbereich und den Anwenderbereich, die in der physischen Schicht der Flashspeicherkarte 31 bereitgestellt sind.
4B zeigt die Zusammensetzung des Authentisierungsbereiches und des Anwenderbereiches in der Dateisystemschicht.
5 zeigt detailliert die Zusammensetzung der Dateisystemschicht.
6 ist eine Darstellung desjenigen Vorganges, bei dem die AOB-Datei „AOB001.SA1" in fünf Teile unterteilt wird, die in Clustern 003, 004, 005, 00A und 00C gespeichert werden.
7 zeigt ein Beispiel für die Einstellungen der Verzeichniseinträge und einer Dateizuweisungstabelle, wenn die AOB-Datei „AOB001.SA1" in einer Vielzahl von Clustern aufgezeichnet ist.
8A und 8B zeigen, welche Verzeichnisse in dem Anwenderbereich und dem Authentisierungsbereich in der Dateisystemschicht bereitgestellt werden, wenn die vorstehend beschriebenen beiden Typen von Dateien in der Anwendungsschicht aufgezeichnet sind, sowie den Umstand, welche Art von Dateien in welchen Verzeichnissen aufgezeichnet sind.
9 zeigt die Entsprechung zwischen der Datei „AOBSA1.KEY" und den AOB-Dateien in den SD_Audio-Verzeichnissen.
10 zeigt die hierarchische Zusammensetzung der Daten in einer AOB-Datei.
11A zeigt in Tabellenform diejenigen Parameter, die durch den Standard ISO/IEC-13818-7 vorgegeben sind.
11B zeigt in Tabellenform diejenigen Parameter, die bei der Codierung einer Datei im Format MPEG-Layer 3 (MP3) verwendet werden.
11C zeigt in Tabellenform diejenigen Parameter, die bei der Codierung einer Datei im Format Windows Media Audio (WMA) verwendet werden.
12 zeigt detailliert die Zusammensetzung von AOB_FRAME.
13 zeigt, wie die Bytelänge der Audiodaten in jedem von drei AOB_FRAMEs eingestellt wird.
14 zeigt die Entsprechung zwischen der Abtastfrequenz (sampling_frequency) und der Anzahl der in AOB_ELEMENT enthaltenen AOB_FRAMEs.
15 zeigt Beispiele für die Abspieldauern von AOB_ELEMENTs und die Abspieldauern von AOB_FRAMEs.
16 zeigt, was wiedergegeben wird, wenn die in einer AOB-Datei aufgezeichneten AOBs und AOB_BLOCKs aufeinanderfolgend abgespielt werden.
17 zeigt detailliert die Zusammensetzung eines Spiellistenverwalters (PlayManager) und eines Spurverwalters (TrackManager), die bei den Ausführungsbeispielen verwendet werden.
18 zeigt die Größen des Spiellistenverwalters (PlayManager) und des Spurverwalters (TrackManager).
19 zeigt die Entsprechung zwischen den TKIs aus der Darstellung in 17 und den AOBs und den AOB-Dateien aus der Darstellung in 16.
20 zeigt detailliert die Datenzusammensetzung von TKTMSRT aus der Darstellung in 17.
21 zeigt ein Beispiel für TKTMSRT.
22 zeigt detailliert die Zusammensetzung von TKGI.
23A und 23B zeigen die Zusammensetzung von BIT.
23C zeigt das Time_Length-Feld (Zeitlängenfeld).
24 zeigt Cluster 007 bis 00E, in denen die AOBs gespeichert werden, die aus AOB_ELEMENT#1 bis AOB_ELEMENT#4 zusammengesetzt sind.
25 zeigt, wie AOB_FRAME#x+1, das als Nächstes abgespielt werden soll, eingestellt wird, wenn eine Vorwärtssuche beginnend ab AOB_FRAME#x in einem willkürlichen AOB_ELEMENT#y in einem AOB vorgenommen werden soll.
26A und 26B zeigen, wie AOB, AOB_ELEMENT und AOB_FRAME, die einem willkürlichen Abspielzeitcode entsprechen, spezifiziert sind.
27A und 27B zeigen das Löschen einer Spur.
28A zeigt den Spurverwalter (Trackmanager), nachdem das Löschen einer Spur mehrfach ausgeführt worden ist.
28B zeigt, wie eine neue TKI und eine AOB-Datei geschrieben werden, wenn „nicht verwendete" TKIs in dem Spurverwalter (Trackmanager) vorhanden sind.
29A und 29B zeigen die eingestellten TKIs, wenn zwei Spuren zu einer neuen Spur kombiniert werden.
30A zeigt ein AOB vom Typ 1 (Type1-AOB).
30B zeigt AOBs vom Typ 2 (Type2-AOBs).
31A zeigt die Kombination einer Vielzahl von Spuren zu einer einzigen Spur für eine Kombination von AOBs vom Typ 1 und Typ 2 und Typ 2 und Typ 1.
31B zeigt die Kombination einer Vielzahl von Spuren zu einer einzigen Spur für eine Kombination von AOBs vom Typ 1 und Typ 2 und Typ 2 und Typ 2 und Typ 1.
32A zeigt ein Muster, bei dem ein AOB vom Typ 1 am Ende einer vorhergehenden Spur und ein AOB vom Typ 1 am Anfang einer nachfolgenden Spur vorhanden sind.
32B zeigt ein Muster, bei dem ein AOB vom Typ 1 am Ende einer ersten Spur und ein AOB vom Typ 2 am Anfang einer nachfolgenden Spur vorhanden sind.
32C zeigt ein Muster, bei dem AOBs vom Typ 1 und Typ 2 am Ende einer ersten Spur und AOBs vom Typ 1 am Anfang einen nachfolgenden Spur vorhanden sind.
32D zeigt ein Muster, bei dem AOBs vom Typ 1 und Typ 2 am Ende einer ersten Spur und AOBs vom Typ 1 und Typ 2 am Anfang einen nachfolgenden Spur vorhanden sind.
32E zeigt ein Muster, bei dem zwei AOBs vom Typ 2 am Ende einer ersten Spur und eines vom Typ 1 am Anfang einer nachfolgenden Spur vorhanden sind.
33A und 33B zeigen die Unterteilung einer Spur in zwei Spuren.
34A und 34B zeigen den Inhalt der SD_Audio-Verzeichniseinträge in dem SD_Audio-Verzeichnis, das die AOB-Datei „AOB003SA1" enthält, vor und nach dem Unterteilen der Spur.
35A zeigt die Unterteilung eines AOB mitten durch AOB_ELEMENT#2.
35B zeigt zwei AOBs, nämlich AOB#1 und AOB#2, die durch Unterteilen eines AOB mitten durch AOB_ELEMENT#2 ermittelt worden sind.
36 zeigt, wie BIT eingestellt wird, wenn ein AOB, wie in 35 gezeigt ist, unterteilt wird.
37 zeigt ein spezifisches Beispiel für Änderungen in BIT vor und nach der Unterteilung.
38 zeigt ein spezifisches Beispiel für Änderungen in TKTMSRT vor und nach der Unterteilung.
39A zeigt das Format von DPL_TK_SRP.
39B zeigt das Format von PL_TK_SRP.
40 zeigt die wechselseitige Beziehung zwischen Default_Playlist_Information, den TKIs und den AOB-Dateien.
41 zeigt als Beispiel angegebene Einstellungen für Default_Playlist und einige PLIs.
42 zeigt, wie DPL_TK_SRPs TKIs entsprechen, wobei dieselbe Notation wie in 40 verwendet wird.
43A und 43B zeigen, wie die Reihenfolge der Spuren neuangeordnet wird.
44A und 44B zeigen, wie Default_Playlist, TrackManager und AOB_Dateien aktualisiert werden, wenn DPL_TK_SRP#2 und TKI#2 aus der Darstellung in 40 gelöscht werden.
45A und 45B zeigen, wie ein neues TKI und DPL_TK_SRP geschrieben werden, wenn eine „nicht verwendete" TKI und DPL_TK_SRP vorhanden sind.
46A und 46B zeigen, wie Spuren kombiniert werden.
47A und 47B zeigen, wie eine Spur unterteilt wird.
48 zeigt das Aussehen einer tragbaren Abspielvorrichtung für eine Flashspeicherkarte 31 der vorliegenden Ausführungsbeispiele.
49 zeigt ein Beispiel für die Anzeige auf einem LCD-Schirm, wenn eine Spielliste (Playlist) ausgewählt ist.
50A bis 50E zeigen Beispiele für die Anzeige auf dem LCD-Schirm, wenn eine Spur ausgewählt ist.
51A bis 51C zeigen Beispielsoperationen bei einem jog dial.
52 zeigt die interne Zusammensetzung der Wiedergabevorrichtungen.
53 zeigt, wie Dateien in den Doppelpuffer 15 hinein und aus diesem heraus übertragen werden.
54A und 54B zeigen, wie Bereiche in dem Doppelpuffer 15 zyklisch unter Verwendung von Ringzeigern zugewiesen werden.
55 ist ein Flussdiagramm, das die AOB-Datei-Leseprozedur zeigt.
56 ist ein Flussdiagramm, das die AOB-Datei-Ausgabeprozedur zeigt.
57 ist ein Flussdiagramm, das die AOB-Datei-Ausgabeprozedur zeigt.
58 ist ein Flussdiagramm, das die AOB-Datei-Ausgabeprozedur zeigt.
59A bis 59D zeigen, wie der Abspielzeitcode, der in dem Abspielzeitcodeframe auf dem LCD-Schirm 5 angezeigt wird, entsprechend der Aktualisierung der veränderlichen Abspielzeit (Play_time) aktualisiert wird.
60 ist ein Flussdiagramm, das die Verarbeitung in der CPU 10 zeigt, wenn die Vorwärtssuchfunktion verwendet wird.
61A bis 61D zeigen, wie der Abspielzeitcode inkrementiert wird, wenn die Vorwärtssuchfunktion verwendet wird.
62A und 62B zeigen spezifische Beispiele dafür, wie die Zeitsuchfunktion verwendet wird.
63 ist ein Flussdiagramm, das die Verarbeitung in einem Bearbeitungssteuerprogramm zeigt.
64 ist ein Flussdiagramm, das die Verarbeitung in dem Bearbeitungssteuerprogramm zeigt.
65 ist ein Flussdiagramm, das die Verarbeitung in dem Bearbeitungssteuerprogramm zeigt.
66 zeigt ein Beispiel für eine Aufzeichnungsvorrichtung zum Aufzeichnen von Daten auf der Flashspeicherkarte 31.
67 zeigt die Hardwarezusammensetzung der Aufzeichnungsvorrichtung.
68 ist ein Flussdiagramm, das die Verarbeitung während des Aufzeichnens zeigt.
69 zeigt die Hardwarezusammensetzung der Flashspeicherkarte 31.
70 zeigt die Kommunikationssequenz, die dann verwendet wird, wenn eine mit der Flashspeicherkarte 31 verbundene Abspielvorrichtung den Verschlüsselungsschlüssel FileKey liest und AOBs abspielt.
71 zeigt Einzelheiten im Zusammenhang mit der Kommunikationssequenz, die verwendet wird, wenn die wechselseitige Authentisierung von 70 vorgenommen wird.
Beschreibung der bevorzugten Ausführungsbeispiele
Nachfolgend wird eine Halbleiterspeicherkarte (Flashspeicherkarte), die ein Ausführungsbeispiel der vorliegenden Erfindung darstellt, unter Bezugnahme auf die beigefügten Figuren beschrieben.
Die nachfolgenden Abschnitte sind hierarchisch unter Verwendung von Abschnittsnummern gemäß nachfolgender Notation angeordnet.
{x1-x2_x3-x4}
Die Länge einer Abschnittsnummer zeigt die Ebene des Themas in der Hierarchie. So bezeichnet beispielsweise die Zahl x1 die Nummer der Zeichnung, auf die in der Erklärung Bezug genommen wird. Die Zeichnungen, die dieser Beschreibung beigefügt sind, sind in derjenigen Reihenfolge durchnummeriert, in der auf sie in der Beschreibung Bezug genommen wird, sodass die Reihenfolge der Zeichnungen in etwa der Reihenfolge der Erklärung entspricht. Die Erklärung bestimmter Zeichnungen wurde in Abschnitte unterteilt, wobei die Abschnittsnummer x2 die Abschnittsnummer eines Abschnittes in der Erklärung einer Figur angibt, die mit der Abschnittsnummer x1 bezeichnet ist. Die Abschnittsnummer x3 bezeichnet die Nummer einer zusätzlichen Figur, die dafür vorgesehen ist, Details des mit der Abschnittsnummer x2 bezeichneten Abschnittes zu zeigen. Schließlich bezeichnet die Abschnittsnummer x4 die Nummer eines Abschnittes in der Erklärung dieser zusätzlichen Figur.
Erstes Ausführungsbeispiel
{1-1_2} Aussehen der Flashspeicherkarte 31
Die Erklärung beginnt mit dem Aussehen der Flashspeicherkarte 31. 1 zeigt das Aussehen der Flashspeicherkarte 31 bei einer Betrachtung von oben, wohingegen 2 das Aussehen der Flashspeicherkarte 31 bei einer Betrachtung von unten zeigt. Wie in 1 und 2 gezeigt ist, weist die Flashspeicherkarte 31 in etwa die gleiche Größe wie eine Briefmarke auf und ist daher in etwa derart groß, dass sie in der Hand gehalten werden kann. Ihre ungefähren Abmessungen entsprechen einer Länge von 32,0 mm, einer Breite von 24,0 mm und einer Dicke von 2,0 mm.
Die Flashspeicherkarte 31 umfasst an ihrem unteren Rand neun Anschlüsse, durch die die Karte mit einer kompatiblen Vorrichtung verbunden werden kann, sowie auf der einen Seite einen Schutzschalter 32, durch den ein Anwender in die Lage versetzt wird einzustellen, ob ein Überschreiben des gespeicherten Inhaltes der Flashspeicherkarte 31 erlaubt oder verboten ist.
{3-1} Physischer Aufbau der Flashspeicherkarte 31
3 zeigt die hierarchische Struktur der Halbleiterspeicherkarte (nachstehend als „Flashspeicherkarte 31" bezeichnet) des vorliegenden Ausführungsbeispieles. Wie in 3 gezeigt ist, ist die Flashspeicherkarte 31 mit einer physischen Schicht, einer Dateisystemschicht und einer Anwendungsschicht auf dieselbe Weise wie eine DVD (Digital Video Disc) ausgebildet. Es unterscheiden sich die logischen und physischen Zusammensetzungen dieser Schichten jedoch stark von denjenigen auf einer DVD.
{3-2} Physische Schicht der Flashspeicherkarte 31
Nachfolgend wird die physische Schicht der Flashspeicherkarte 31 beschrieben. Die Flashspeicherkarte setzt sich aus einer Vielzahl von Sektoren zusammen, von denen jeder 512 Byte digitaler Daten speichert. So weist beispielsweise eine 64-MB-Flashspeicherkarte 31 eine Speicherkapazität von 67.108.864 (= 64 × 1024 × 1024) Byte auf, weshalb diese Karte 131.072 (= 67.108.864/512) gültige Sektoren aufweist. Wird die Anzahl der Ersetzungssektoren, die für den Fall des Auftretens von Fehlern, bereitstehen, abgezogen, so liegt die Anzahl der verbleibenden gültigen Sektoren, in die verschiedene Arten von Daten geschrieben werden können, bei ungefähr 128.000.
{3-2_4A-1} Drei Bereiche in der physischen Schicht
Die in 4A gezeigten drei Bereiche sind in dem Speichergebiet vorgesehen, das sich aus diesen gültigen Sektoren zusammensetzt. Die Bereiche sind der Spezialbereich", "der Authentisierungsbereich" und der „Anwenderbereich", die nachstehend detailliert beschrieben werden. Der Anwenderbereich zeichnet sich dadurch aus, dass eine Vorrichtung, mit der die Flashspeicherkarte 31 verbunden ist, verschiedene Arten von Daten frei aus diesem Bereich lesen oder in diesen Bereich schreiben kann. Gebiete innerhalb des Anwenderbereiches werden von einem Dateisystem verwaltet.
Der Spezialbereich speichert eine Medienkennung (media ID), die ein Wert ist, der jeder Flashspeicherkarte 31 eindeutig zugewiesen ist. Im Gegensatz zum Anwenderbereich ist dieser Bereich ein Nurlesebereich, weshalb die in dem Spezialbereich gespeicherte Medienkennung nicht geändert werden kann.
Der Authentisierungsbereich ist ein beschreibbarer Bereich entsprechend dem Anwenderbereich. Dieser Bereich unterscheidet sich von dem Anwenderbereich dadurch, dass eine Vorrichtung, die mit der Flashspeicherkarte 31 verbunden ist, auf den Authentisierungsbereich nur dann zugreifen kann (das heißt in diesen Daten schreiben oder von diesem Daten lesen kann), wenn die Flashspeicherkarte 31 und die Vorrichtung einander zunächst bestätigt haben, dass sie authentische Vorrichtungen sind. Mit anderen Worten, es können Daten nur dann aus dem Authentisierungsbereich gelesen oder in diesen geschrieben werden, wenn eine wechselseitige Authentisierung erfolgreich von der Flashspeicherkarte 31 und der mit der Flashspeicherkarte 31 verbundenen Vorrichtung vorgenommen worden ist.
{3-2_4A-2} Verwendung der drei Bereiche in der physischen Schicht
Schreibt die mit der Flashspeicherkarte 31 verbundene Vorrichtung Daten auf die Flashspeicherkarte 31, so ist derjenige Bereich, der zur Speicherung dieser Daten verwendet wird, davon abhängig, ob für die geschriebenen Daten ein Urheberrechtsschutz erforderlich ist. Werden Daten, die eines urheberrechtlichen Schutzes bedürfen, auf die Flashspeicherkarte 31 geschrieben, so werden die Daten unter Verwendung eines vorgegebenen Verschlüsselungsschlüssels (der „FileKey" genannt wird) verschlüsselt, bevor sie in das Anwendergebiet geschrieben werden. Dieser Filekey kann von dem Urheberrechtsinhaber frei eingestellt werden. Der FileKey bietet bis zu einem gewissen Grad einen Urheberrechtsschutz, wobei der Filekey, der zur Verschlüsselung der Daten verwendet wird, selbst verschlüsselt wird, um den Urheberrechtsschutz noch besser zu machen. Ein beliebiger Wert, der durch Abziehen der in dem Spezialbereich gespeicherten Medienkennung mittels einer vorgegebenen Berechnung ermittelt wird, kann zur Verschlüsselung des FileKey verwendet werden. Der auf diese Weise erzeugte verschlüsselte FileKey wird in dem Authentisierungsbereich gespeichert.
Da diejenigen Daten, die eines Urheberrechtsschutzes bedürfen, einem zweistufigen Verschlüsselungsvorgang unterzogen werden, bei dem die Daten unter Verwendung eines FileKey verschlüsselt werden, der selbst auf der Grundlage der Medienkennung verschlüsselt ist, wird eine Urheberrechtsverletzung, so beispielsweise das Erstellen von nicht autorisierten Kopien dieser Daten, äußerst schwierig.
{3-2_4B-1} Überblick über das Dateisystem
Es ist einsichtig, dass die Zusammensetzung der physischen Schicht der Flashspeicherkarte 31 den Urheberrechtsschutz der auf die Flashspeicherkarte 31 geschriebenen Daten vergrößert. Nachfolgend wird die Dateisystemschicht beschrieben, die in dieser physischen Schicht vorhanden ist. Während sich die Dateisystemschicht einer DVD eines Dateisystems vom UDF-Typ (Universal Disk Format UDF, universelles Diskformat) bedient, beruht die Dateisystemschicht der Flashspeicherkarte 31 auf einem Dateisystem vom FAT-Typ (File Allocation Table FAT, Dateizuweisungstabelle), das bei ISO/IEC 9293 beschrieben ist.
4B zeigt die Zusammensetzung des Authentisierungsbereiches und des Anwenderbereiches in der Dateisystemschicht. Wie in 4B gezeigt ist, enthalten der Authentisierungsbereich und der Anwenderbereich in dem Dateisystem jeweils „Partitionsbootsektoren", eine „Dateizuweisungstabelle" (FAT), ein „Rootverzeichnis" und einen „Datenbereich", was bedeutet, dass der Authentisierungsbereich und der Anwenderbereich dieselbe Zusammensetzung aufweisen. 5 zeigt die verschiedenen Teile dieser Dateisysteme eingehender. Nachfolgend wird die Zusammensetzung des Anwenderbereiches unter Bezugnahme auf 4A, 4B und 5 beschrieben.
{3-2_4B-2} Partitionsbootsektoren
Die Partitionsbootsektoren sind Sektoren, die diejenigen Daten speichern, auf die ein Standardpersonalcomputer Bezug nimmt, der mit der Flashspeicherkarte 31 verbunden ist, wenn die Flashspeicherkarte 31 als Bootdisk für das Betriebssystem (operating system OS) des Personalcomputers eingestellt ist.
{3-2_4B-3_5} Datenbereich
Auf den Datenbereich kann durch eine mit der Flashspeicherkarte 31 verbundene Vorrichtung in Einheiten zugegriffen werden, die nicht kleiner als ein „Cluster" sind. Während jeder Sektor auf der Flashspeicherkarte 31 eine Größe von 512 Byte aufweist, ist die Clustergröße gleich 16 KB, weshalb die Dateisystemschicht Daten in Einheiten von 32 Sektoren liest und schreibt.
Der Grund dafür, dass die Clustergröße auf 16 KB eingestellt ist, besteht darin, dass beim Schreiben von Daten auf die Flashspeicherkarte 31 ein Teil der auf der Flashspeicherkarte 31 gespeicherten Daten zunächst gelöscht werden muss, bevor das Schreiben vorgenommen werden kann.
Die kleinste Datenmenge, die auf der Flashspeicherkarte 31 gelöscht werden kann, umfasst 16 KB, weshalb das Einstellen der kleinsten löschbaren Größe als Clustergröße bedeutet, dass Datenschreibvorgänge begünstigt ausgeführt werden. Der Pfeil ff2, der in 5 mit einer gestrichelten Linie bezeichnet ist, zeigt die Vielzahl von Clustern 002, 003, 004, 005, die in dem Datenbereich enthalten sind. Die Zahlen 002, 003, 004, 005, 006, 007, 008 ..., die in 5 gezeigt sind, sind dreistellige hexadezimale Clusternummern, die zur Identifizierung jedes Clusters exklusiv zugewiesen werden. Da die kleinste Einheit, auf die ein Zugriff vorgenommen werden kann, ein Cluster ist, werden die Speicherpositionen innerhalb des Datenbereiches unter Verwendung der Clusternummern angegeben.
{3-2_4B-4_5} Dateizuweisungssystem
Das Dateizuweisungssystem weist eine Dateisystemzusammensetzung entsprechend dem Standard ISO/IEC 9293 auf und besteht daher aus einer Vielzahl von FAT-Werten. Jeder FAT-Wert entspricht einem Cluster und zeigt, welches Cluster nach demjenigen Cluster gelesen werden soll, das dem FAT-Wert entspricht. Der durch eine gestrichelte Linie in 5 gezeigte Pfeil ff1 zeigt die Vielzahl von FAT-Werten 002, 003, 004, 005 ..., die in der Dateizuweisungstabelle enthalten sind. Die Nummern 002, 003, 004, 005 ..., die jedem FAT-Wert zugewiesen sind, zeigen, welches Cluster einem FAT-Wert entspricht, und sind daher die Clusternummern derjenigen Cluster, die den FAT-Werten entsprechen.
{3-2_4B-5_5-1} Rootverzeichniseinträge
Die „Rootverzeichniseinträge" sind Informationen, die zeigen, welche Arten von Dateien in dem Rootverzeichnis vorhanden sind. So können beispielsweise der „Dateiname" (filename) einer bestehenden Datei, die zugehörige „Dateinamenerweiterung" (filename extension), „die Zeit/das Datum der Überarbeitung" (revision time/data) und die „Nummer des ersten Clusters in der Datei", durch die angegeben ist, wo der Anfang der Datei gespeichert ist, als Rootverzeichniseintrag einer Datei geschrieben werden.
{3-2_4B-5_5-2} Verzeichniseinträge für Unterverzeichnisse
Informationen im Zusammenhang mit Dateien in dem Rootverzeichnis werden als Rootverzeichniseinträge geschrieben, wohingegen Informationen im Zusammenhang mit Unterverzeichnissen (subdirectories) nicht als Rootverzeichniseinträge geschrieben werden. Verzeichniseinträge für Unterverzeichnisse werden anstelle dessen in dem Datenbereich erzeugt. In 5 ist der SD_Audio-Verzeichniseintrag, der in dem Datenbereich gegeben ist, ein Beispiel für einen Verzeichniseintrag eines Unterverzeichnisses. Genau wie bei einem Rootverzeichniseintrag umfasst ein SD_Audio-Verzeichniseintrag den „Dateinamen" (filename) einer in diesem Unterverzeichnis vorhandenen Datei, die zugehörige „Dateinamenerweiterung" (filename extension), „die Zeit/das Datum der Überarbeitung" (revision time/data) und „die Nummer des ersten Clusters in der Datei", die zeigt, wo der Anfang der Datei gespeichert ist.
{3-2_4B-5_6-1} Speicherformat für AOB-Dateien
Nachfolgend wird das Dateispeicherverfahren anhand dessen, wie eine Datei namens „AOB001.SA1" in dem SD_Audio-Verzeichnis gespeichert wird, unter Bezugnahme auf 6 beschrieben. Da die kleinste Einheit, in der auf den Datenbereich zugegriffen werden kann, ein Cluster ist, muss die Datei „AOB001.SA1" in dem Datenbereich in Teilen gespeichert werden, die nicht kleiner als ein Cluster sind. Die Datei „AOB001.SA1" wird daher gespeichert, nachdem sie zunächst in Cluster unterteilt worden ist. In 6 ist die Datei „AOB001.SA1" nach Maßgabe der Clustergröße in fünf Teile unterteilt, wobei die sich ergebenden Teile in den Clustern mit den Nummern 003, 004, 005, 00A und 00C gespeichert werden.
{3-2_4B-5_7-1} Speicherformat für AOB-Dateien
Wird die Datei „AOB001.SA1" in Teile unterteilt und gespeichert, so müssen, wie in 7 gezeigt ist, ein Verzeichniseintrag und die Dateizuweisungstabelle eingestellt werden. 7 zeigt ein Beispiel dafür, wie der Verzeichniseintrag und die Dateizuweisungstabelle eingestellt werden müssen, wenn die Datei „AOB001.SA1", die in Teile unterteilt und gespeichert worden ist, gespeichert wird. Wie in 7 gezeigt ist, wird der Anfang der Datei „AOB001.SA1" in dem Cluster 003 gespeichert, weshalb die Clusternummer 003 in „die Nummer des ersten Clusters in der Datei" in dem SD_Audio-Verzeichniseintrag geschrieben wird und dadurch angibt, dass das Cluster den ersten Teil der Datei speichert. Wie in 7 gezeigt ist, werden die nachfolgenden Teile der Datei „AOB001.SA1" in den Clustern 004 und 005 gespeichert. Im Ergebnis gibt, während der FAT-Wert 003 (004) dem Cluster 003 entspricht, das den ersten Teil der Datei „AOB001.SA1" speichert, dieser Wert das Cluster 004 als dasjenige Cluster an, das den nächsten Teil der Datei „AOB001.SA1" speichert. Auf dieselbe Weise geben, wenn die FAT-Werte 004 (005) und 005 (00A) jeweils den Clustern 004 und 005 entsprechen, die die nächsten Teile der Datei „AOB001.SA1" speichern, diese Werte jeweils an, dass das Cluster 005 und das Cluster 006 diejenigen Cluster sind, die die nächsten Teile der Datei „AOB001.SA1" speichern. Durch Lesen der Cluster mit den Clusternnummern, die in diese FAT-Werte in einer Reihenfolge geschrieben sind, die in 7 mit den Pfeilen fk1, fk2, fk3, fk4, fk5 ... bezeichnet ist, können sämtliche durch Unterteilen der Datei „AOB001.SA1" erzeugten Teile gelesen werden. Wie vorstehend erläutert worden ist, kann auf den Datenbereich der Flashspeicherkarte 31 in Einheiten von Clustern zugegriffen werden, von denen jedes mit einem FAT-Wert verknüpft ist. Man beachte, dass der FAT-Wert, der demjenigen Cluster entspricht, das den Endteil einer AOB-Datei speichert (Cluster 00C in dem in 7 gezeigten Beispiel), auf die Clusternummer FFF eingestellt wird, wodurch gezeigt wird, dass das entsprechende Cluster den Endteil einer Datei speichert.
Dies beendet die Erläuterung des Dateisystems in der Flashspeicherkarte 31 der vorliegenden Erfindung. Nachfolgend wird die Anwendungsschicht beschrieben, die in diesem Dateisystem vorhanden ist.
{3-3} Überblick über die Anwendungsschicht in der Flashspeicherkarte 31
Ein Überblick über die Anwendungsschicht in der Flashspeicherkarte 31 ist in 3 gezeigt. Wie durch den mit einer gestrichelten Linie in 3 dargestellten Pfeil PN2 gezeigt ist, setzt sich die Anwendungsschicht auf der Flashspeicherkarte 31 aus Präsen tationsdaten und Navigationsdaten zusammen, die zur Steuerung des Abspielens der Präsentationsdaten verwendet werden. Wie durch den Pfeil PN2 dargestellt ist, enthalten die Präsentationsdaten Mengen bzw. Sätze von Audioobjekten (AOB-Mengen), die durch Codieren derjenigen Audiodaten erzeugt werden, die beispielsweise Musik darstellen. Die Navigationsdaten enthalten einen „Spiellistenverwalter" (PlaylistManager PLMG) und einen Spurverwalter (TrackManager TKMG).
{3-3_8A,B-1} Zusammensetzung des Verzeichnisses
8A und 8B zeigen, welche Art von Verzeichnissen in dem Anwenderbereich und dem Authentisierungsbereich in der Dateisystemschicht vorhanden sind, wenn diese beiden Typen von Daten in der Anwendungsschicht gespeichert sind, sowie welche Dateien in diesen Verzeichnissen angeordnet sind.
Die Dateinamen „SD_AUDIO.PLM" und „SD_AUDIO.TKM" in 8A bezeichnen diejenigen Dateien, in denen der Spiellistenverwalter (PlaylistManager) und der Spurverwalter (TrackManager), die die Navigationsinformationen bilden, gespeichert sind. Hierbei bezeichnen die Dateinamen „AOB001.SA1", „AOB002.SA1", „AOB003.SA1", „AOB004.SA1" ... diejenigen Dateien (AOB-Dateien), die die Audioobjekte speichern, die die Präsentationsdaten sind. Die Buchstaben „SA" in der Dateinamenserweiterung des Dateinamens „AOBOxx.SA1" sind eine Abkürzung für „Secure Audio" (sicheres Audio) und zeigen, dass der gespeicherte Inhalt dieser Datei eines Urheberrechtsschutzes bedarf. Man beachte, dass obwohl nur acht AOB-Dateien in dem Beispiel von 8A gezeigt sind, eine Maximalzahl von 999 AOB-Dateien in einem SD_Audio-Verzeichnis gespeichert werden kann.
Wird für die Präsentationsdaten ein Urheberrechtsschutz benötigt, so wird ein Unterverzeichnis mit dem Namen „SD-Audio directory" (SD-Audio-Verzeichnis) in dem Authentisierungsbereich vorgesehen und eine Verschlüsselungsschlüsselspeicherdatei „AOB-SA1.KEY" in dem SD-Audio-Verzeichnis erzeugt.
8B zeigt die Verschlüsselungsschlüsselspeicherdatei „AOBSA1.KEY", die unter der Bezeichnung „SD-Audio" (das heißt innerhalb des „SD-Audio-Verzeichnisses" gespeichert ist. Die Verschlüsselungsschlüsselspeicherdatei „AOBSA1.KEY" speichert eine Sequenz von Verschlüsselungsschlüsseln, die durch Anordnen einer Vielzahl von Verschlüsselungsschlüsseln in einer vorgegebenen Reihenfolge erzeugt wird.
Das in 8A und 8B gezeigte SD-Audio-Verzeichnis wird von der Plattenfirma, die sich der elektronischen Musikverteilung bedient, auf einem Servercomputer gespeichert. Bestellt ein Verbraucher einen Musikinhalt, so wird das entsprechende SD-Audio-Verzeichnis komprimiert, verschlüsselt und über ein öffentliches Netzwerk an den Verbraucher übertragen. Der Computer des Verbrauchers empfängt das SD-Audio-Verzeichnis entschlüsselt es, dekomprimiert es und erhält so das ursprüngliche SD-Audio-Verzeichnis. Man beachte, dass der Ausdruck „öffentliches Netzwerk" hier eine beliebige Art von Netzwerk bezeichnet, das von der Öffentlichkeit genutzt werden kann, so beispielsweise drahtgebundene Kommunikationsnetzwerke wie ISDN-Netzwerke oder drahtlose Kommunikationsnetzwerke wie Mobiltelefonsysteme. Es ist zudem möglich, dass der Computer eines Verbrauchers eine AOB-Datei von einem von der Plattenfirma betriebenen Servercomputer herunterlädt und anschließend ein SD-Audio-Verzeichnis, so beispielsweise das in 8A und 8B gezeigte, auf der Flashspeicherkarte 31 erzeugt.
{3-3_9-1} Entsprechung zwischen der Datei „AOBSA1.KEY" und den AOB-Dateien
9 zeigt die Entsprechung zwischen der Datei „AOBSA1.KEY" in dem SD-Audio-Verzeichnis und den AOB-Dateien. Die FileKeys, die verwendet werden, wenn die Dateien in dem in 9 gezeigten Anwenderbereich verschlüsselt werden, sind in der entsprechenden Verschlüsselungsschlüsselspeicherdatei in dem Authentisierungsbereich gespeichert.
Die verschlüsselten AOB-Dateien und die Verschlüsselungsschlüsselspeicherdatei entsprechen den nachstehend beschriebenen vorgegebenen Regeln (1), (2) und (3).

(1) Die Verschlüsselungsschlüsselspeicherdatei wird in einem Verzeichnis mit denselben Verzeichnisnamen wie dasjenige Verzeichnis angeordnet, in dem die verschlüsselte Datei gespeichert ist. Wie in 9 gezeigt ist, sind die AOB-Dateien entsprechend dieser Regel in dem SD-Audia-Verzeichnis in dem Anwenderbereich und die Verschlüssefungsschlüsselspeicherdatei in einem Verzeichnis namens SD-Audio-Verzeichnis in dem Authentisierungsbereich angeordnet.
(2) Der Verschlüsselungsschlüsselspeicherdatei wird ein Dateiname gegeben, der durch Kombinieren der ersten drei Buchstaben des Dateinamens der AOB-Dateien in dem Da tenbereich mit der vorgegebenen Erweiterung „.key" erzeugt wird. Ist der Dateiname einer AOB-Datei gleich „AOB001.SA1", so wird der Verschlüsselungsschlüsselspeicherdatei der Dateiname „AOBSA1.KEY" gegeben, der durch Hinzufügen der ersten drei Zeichen „AOB", „SA1" und der Erweiterung „.key" erzeugt wird, was durch die Pfeile nk1 und nk2 in 9 zeigt ist.
(3) Der Dateiname einer AOB-Partei wird mit einer Seriennummer versehen, die die Position des FileKey zeigt, der diesem Audioobjekt in der Sequenz von Verschlüsselungsschlüsseln entspricht, die in der Verschlüsselungsschlüsselspeicherdatei vorhanden sind.

Die FileKey-Einträge #1, #2, #3, ... #8 zeigen die ersten Positionen derjenigen Bereiche, in denen die entsprechenden FileKeys in der Verschlüsselungsschlüsselspeicherdatei gespeichert sind. Die Dateinamen der AOB-Dateien werden den Seriennummern „001", „002", „003", „004", ... zugeordnet. Diese Seriennummern zeigen die Positionen der entsprechenden FileKeys in der Verschlüsselungsschlüsselsequenz, sodass derjenige File-Key, der zur Verschlüsselung mit jeder AOB-Datei verwendet worden ist, in dem „File-Key-Eintrag" mit derselben Seriennummer vorhanden ist. In 9 zeigen die Pfeile Ak1, Ak2, Ak3, ... die Entsprechung zwischen den AOB-Dateien und den FileKeys. Mit anderen Worten, die Datei „AOB001.SA1" entspricht demjenigen FileKey, dessen Speicherposition durch „FileKey Entry#1" (FileKey-Eintrag #1) angegeben ist, die Datei „AOB002.SA1" entspricht demjenigen FileKey, dessen Speicherposition durch „File-Key Entry#2" (FileKey-Eintrag #2) angegeben ist, und die Datei „AOB003.SA1" entspricht demjenigen FileKey, dessen Speicherposition durch „FileKey Entry#3" (FileKey-Eintrag #3) angegeben ist. Aus Regel (3) ergibt sich, dass verschiedene FileKeys zur Verschlüsselung verschiedener AOB-Dateien verwendet werden, wobei diese FileKeys in „FileKey-Einträgen" mit den Seriennummern „001", „002", „003", „004" etc. gespeichert werden, die in den Dateinamen der entsprechenden AOB-Dateien gegeben sind.
Da jede AOB-Datei unter Verwendung eines anderen FileKey verschlüsselt wird, versetzt das Offenliegen des Verschlüsselungsschlüssels, der für eine AOB-Datei verwendet wird, Anwender nicht in die Lage, andere AOB-Dateien zu entschlüsseln. Hieraus ergibt sich, dass bei Speicherung von AOB-Dateien auf einer Flashspeicherkarte 31 in verschlüsselter Form der Schaden, der durch das Offenliegen eines FileKey verursacht wird, minimiert werden kann.
{3-3_10-1} Interne Zusammensetzung einer AOB-Datei
Nachfolgend wird die interne Zusammensetzung einer AOB-Datei beschrieben. 10 zeigt die hierarchische Datenstruktur einer AOB-Datei. Die erste Ebene in 10 zeigt die AOB-Datei, während die zweite Ebene das Audioobjekt (AOB) selbst zeigt. Die dritte Ebene zeigt AOB_BLOCKs, die vierte Ebene ein AOB_ELEMENT und die fünfte Ebene ein AOB_FRAME.
Das AOB_FRAME in der fünften Ebene von 10 ist die kleinste Einheit, die das AOB bildet und setzt sich aus Audiodaten im ADTS-Format (Audio Data Transport Stream ADTS, Audiodatentransportstrom) und einem ADTS-Header zusammen. Audiodaten im ADTS-Format werden entsprechend dem MPEG2-AAC-Format (Low Complexity Profile) verschlüsselt und sind Stromdaten, die mit einer Übertragungsrate von 16 Kbps bis 144 Kbps abgespielt werden können. Man beachte, dass die Übertragungsrate für die PCM (Pulse Code Modulation PCM, Pulscodemodulation), die auf einer herkömmlichen Kompaktdisk aufgezeichnet ist, gleich 1,5 Mbps ist, sodass sich Daten im ADTS-Format üblicherweise einer niedrigeren Übertragungsrate als die PCM bedienen. Die Zusammensetzung der Datei in einer Sequenz von AOB_FRAMEs ist die gleiche wie die Sequenz von Audioframes, die in einem Audiodatentransportstrom enthalten ist, der von einem elektronischen Musikverteilungsdienst übertragen wird. Dies bedeutet, dass der Audiodatentransportstrom mit einer beabsichtigen Speicherung als AOB_FRAME-Sequenz entsprechend dem MPEG2-AAC-Standard codiert, verschlüsselt und in einem öffentlichen Netzwerk an den Verbraucher übertragen wird. AOB-Dateien werden durch Unterteilen des übertragenen Audiodatentransportstroms in eine Sequenz von AOB_FRAMEs und Speichern dieser AOB_FRAMEs erzeugt.
{3-3_10-1_11} MPEG2-AAC
Der Standard MPEG2-AAC wird detailliert bei ISO/IEC 13818-7:1997(E) „Information Technology – Generic Coding of Moving Pictures and Associated Audio Information – Part 7 Advanced Audio Coding (AAC)" beschrieben.
Man beachte, dass Audioobjekte nur entsprechend MPEG2-AAC unter Verwendung der Parameter der in 11A gezeigten Parametertabelle komprimiert werden können, die bei ISO/IEC 13818-7 definiert ist. Die Parametertabelle setzt sich aus einer Spalte „Parameter", einer Spalte „Wert" und einer Spalte „Kommentar" zusammen.
Die Angabe „Profil" in der Spalte „Parameter" zeigt, dass nur ein LC-Profil verwendet werden kann, wie von ISO/IEC 13818-7 gefordert. Die Angabe „sampling_frequency#index" in der Spalte „Parameter" zeigt, dass die Abtastfrequenzen 48 kHz, 44,1 kHz, 32 kHz, 24 kHz, 22,05 kHz und 16 kHz verwendet werden können.
Die Angabe „number_of_data_block_in_frame" in der Spalte „Parameter" zeigt, dass das Verhältnis eines Headers zu raw data block verwendet werden kann.
Man beachte, dass ungeachtet der Tatsache, dass obwohl die vorliegende Erklärung denjenigen Fall beschreibt, in dem AOB_FRAMEs entsprechend dem MPEG-AAC-Format codiert werden, AOB_FRAMEs anstelle dessen auch entsprechend einem anderen Format codiert werden können, so beispielsweise entsprechend dem MPEG-Layer3-Format (MP3-Format) oder dem Windows-Media-Audio-Format (WMA-Format). Ist dies der Fall, so müssen die in den Parametertabellen von 11B oder 11C gezeigten Parameter verwendet werden.
{3-3_10-2_12} Zusammensetzung eines AOB_FRAME
Obwohl jedes AOB_FRAME Audiodaten enthält, die entsprechend den vorstehend aufgeführten Einschränkungen codiert sind, ist die Datenlänge der Audiodaten in jedem AOB_FRAME auf eine Abspielzeit von lediglich 20 ms beschränkt. Da MPEG2-AAC ein Codierverfahren mit veränderlicher Bitrate (variable bitrate VBR) ist, variiert die Datenlänge der Audiodaten in jedem AOB_FRAME. Nachfolgend wird die Zusammensetzung eines AOB_FRAME unter Bezugnahme auf 12 beschrieben.
Die erste Ebene in 12 zeigt die Gesamtzusammensetzung, während die zweite Ebene zeigt, wie jeder Teil eines AOB_FRAME verschlüsselt ist. Aus der Figur ist ersichtlich, dass der ADTS-Header einem unverschlüsselten Teil entspricht. Die Audiodaten enthalten sowohl einen verschlüsselten Teil wie auch einen unverschlüsselten Teil. Der verschlüsselte Teil der Audiodaten setzt sich aus einer Vielzahl von 8 Bit umfassenden Stücken bzw. Elementen verschlüsselter Daten zusammen, von denen jedes durch Verschlüsseln eines 8 Bit umfassenden Stückes bzw. Elementes von Audiodaten unter Verwendung eines 56 Bit umfassenden FileKey erzeugt wird. Wird eine Verschlüsselung an 64 Bit umfassenden Stücken bzw. Elementen der Audiodaten vorgenommen, so ist der unverschlüsselte Teil der Audiodateien einfach ein Endteil der Daten, der nicht verschlüsselt werden kann, da er weniger als 64 Bit aufweist.
Die dritte Ebene von 12 zeigt den Inhalt des ADTS-Headers, der in dem unverschlüsselten Teil des AOB_FRAME vorhanden ist. Der ADTS-Header weist eine Länge von 7 Byte auf und enthält ein 12 Bit umfassendes Synchronisierungswort (synch word) (bei FFF eingestellt), die Datenlänge der Audiodaten in diesem AOB_FRAME und die Abtastfrequenz, die bei der Codierung der Audiodaten verwendet worden ist.
{3-3_10-3_13} Einstellen der Bytelänge eines AOB_FRAME
13 zeigt, wie die Bytelänge der Audiodaten in jedem der drei AOB_FRAMEs eingestellt ist. Wie in 13 gezeigt ist, ist die Datenlänge von den in AOB_FRAME#1 enthaltenen Audiodaten #1 (audio data #1) gleich x1, die Datenlänge von den in AOB_FRAME#2 enthaltenen Audiodaten #1 (audio data #1) gleich x2 und die Datenlänge von den in AOB_FRAME#3 enthaltenen Audiodaten #1 (audio data #1) gleich x3. Sind die Datenlängen x1, x2 und x3 alle verschieden, so wird die Datenlänge x1 in den ADTS-Header von AOB_FRAME#1, die Datenlänge x1 in den ADTS-Header von AOB_FRAME#2 und die Datenlänge x3 in den ADTS-Header von AOB_FRAME#3 geschrieben.
Obwohl die Audiodaten verschlüsselt sind, ist der ADTS-Header nicht verschlüsselt, sodass eine Abspielvorrichtung die Datenlänge der Audiodaten in einem AOB_FRAME durch Lesen der Datenlänge in Erfahrung bringen kann, die in dem ADTS-Header des AOB_FRAME gegeben ist.
Dies beendet die Erläuterung eines AOB_FRAME.
{3-3_10-4} AOB_ELEMENT
Nachfolgend wird das AOB_ELEMENT gemäß Darstellung in der vierten Ebene von 10 beschrieben.
Ein „AOB_ELEMENT" ist eine Gruppe von aufeinanderfolgenden AOB_FRAMEs. Die Anzahl von AOB_FRAMEs in einem AOB_ELEMENT hängt von demjenigen Wert, der als Abtasffrequenzindex (sampling_frequency_index), siehe 11A, eingestellt ist, und dem verwendeten Codierverfahren ab. Die Anzahl von AOB_FRAMEs in einem AOB_ELEMENT wird derart eingestellt, dass die Gesamtabspielzeit der enthaltenen AOB_FRAMEs bei etwa 2 s liegt, wobei diese Zahl von der Abtastfrequenz und dem verwendeten Codierverfahren abhängt.
{3-3_10-5_14} Anzahl von AOB_FRAMEs in einem AOB_ELEMENT
14 zeigt die Entsprechung zwischen der Abtastfrequenz und der Anzahl von in einem AOB_ELEMENT enthaltenen AOB_FRAMEs. Die Anzahl N gemäß 14 stellt die Abspieldauer eines AOB_ELEMENT in Sekunden dar. Wird MPEG-ACC als Codierverfahren verwendet, so ist der Wert von N gleich "2".
Ist die Abtastfrequenz (sampling_frequency) gleich 48 kHz, so ist die Anzahl von in einem AOB_ELEMENT enthaltenen AOB_FRAMEs gleich 94 (= 47 × 2), während für den Fall, dass die Abtastfrequenz (sampling_frequency) gleich 44,1 kHz ist, die Anzahl von in einem AOB_ELEMENT enthaltenen AOB_FRAMEs gleich 86 (= 43 × 2) ist. Ist die Abtastfrequenz (sampling_frequency) gleich 32 kHz, so ist die Anzahl von AOB_FRAMEs gleich 64 (= 32 × 2), ist die Abtastfrequenz (sampling_frequency) gleich 24 kHz, so ist die Anzahl von AOB_FRAMEs gleich 48 (= 24 × 2), ist die Abtastfrequenz (sampling_frequency) gleich 22,05 kHz, so ist die Anzahl von AOB_FRAMEs gleich 44 (= 22 × 2), und ist die Abtastfrequenz (sampling_frequency) gleich 16 kHz, so ist die Anzahl von in einem AOB_ELEMENT enthaltenen AOB_FRAMEs gleich 32 (= 16 × 2). Wird jedoch eine Bearbeitungsoperation, so beispielsweise die Unterteilung eines AOB, vorgenommen, so kann die Anzahl vom in einem AOB_ELEMENT enthaltenen AOBs am Anfang oder Ende eines AOB kleiner als die auf diese Weise berechnete Zahl sein.
Ist kein Header oder eine andere Spezialinformation für jedes AOB_ELEMENT vorhanden, so wird die Datenlänge jedes AOB_ELEMENT anstatt dessen durch eine Zeitsuchtabelle angegeben.
{3-3_10-6_15} Ein Beispiel für Abspieldauern von AOB_ELEMENTs und AOB_FRAMEs
15 zeigt ein Beispiel für die Abspieldauern von AOB_ELEMENTs und AOB_FRAMEs. Die erste Ebene in 15 zeigt eine Vielzahl von AOB_BLOCKs, wäh rend die zweite Ebene eine Vielzahl von AOB_ELEMENTs zeigt. Die dritte Ebene zeigt eine Vielzahl von AOB_FRAMEs.
Wie in 15 gezeigt ist, weist ein AOB_ELEMENT eine Abspieldauer von etwa 2,0 s auf, während ein AOB_FRAME eine Abspieldauer von 20 ms aufweist. "TMSRT_Entry" (TMSRT_Eintrag) gemäß Vergabe an jedes AOB_ELEMENT zeigt, dass die Datenlänge von jedem AOB_ELEMENT in der Zeitsuchtabelle gegeben ist. Durch Bezugnahme auf die TMSRT_Einträge kann eine Abspielvorrichtung eine Vorwärts- oder Rückwärtssuche vornehmen, bei der beispielsweise intermittierende Musikfetzen durch wiederholtes Abspielen von 240 ms von Audiodaten und anschließendes Überspringen von 2 s von Audiodaten in der gewünschten Richtung ausgeführt werden.
{3-3_10-7} AOB_BLOCK
Dies beendet die Erläuterung eines AOB_ELEMENT. Nachfolgend wird das Konzept von AOB_BLOCKs gezeigt, die auf der dritten Ebene der Dateizusammensetzung einer AOB_Datei, siehe 10, gezeigt sind.
Jeder „AOB_BLOCK" setzt sich jeweils aus gültigen AOB_ELEMENTs zusammen. Es existiert nur ein AOB_BLOCK in jeder AOB-Datei (AOB_FILE). Während ein AOB_ELEMENT eine Abspieldauer von etwa 2 s aufweist, weist ein AOB_BLOCK eine maximale Abspieldauer von 8,4 min auf. Die Grenze von 8,4 min ist auferlegt, um die Größe jeder Zeitsuchtabelle auf 504 Byte oder weniger zu begrenzen.
{3-3_10-8} Beschränkung der Zeitsuchtabelle
Nachfolgend wird detailliert beschrieben, warum die Größe der Zeitsuchtabelle durch Begrenzen der Abspieldauer beschränkt wird.
Nimmt eine Abspielvorrichtung eine Vorwärts- oder Rückwärtssuche vor, so überspringt die Abspielvorrichtung das Lesen von 2 s von Audiodaten vor dem Abspielen von 240 ms. Beim Überspringen von 2 s von Daten könnte die Abspielvorrichtung sich theoretisch auf die in den ADTS-Headern von AOB_FRAMEs gezeigten Datenlängen beziehen, obwohl dies bedingen würde, dass die Abspielvorrichtung aufeinanderfolgend 100 (2 s durch 20 ms) AOB_FRAMEs erfassen müsste, nur um 2 s von Audiodaten zu über springen. Dies würde eine erhebliche Verarbeitungsbelastung für die Abspielvorrichtung bedeuten.
Um die Verarbeitungsbelastung der Abspielvorrichtung zu verringern, können die gelesenen Adressen für Daten in Intervallen von 2 s in eine Zeitsuchtabelle geschrieben werden, auf die die Abspielvorrichtung dann bei der Durchführung einer Vorwärts- oder Rückwärtssuche Bezug nimmt. Durch Schreiben von Informationen, die das schnelle Auffinden von gelesenen Adressen, die sich 2 oder 4 s davor oder danach befinden, in der Zeitsuchtabelle ermöglichen (wobei diese Informationen die Datengrößen von AOB_ELEMENTs sind), muss eine Abspielvorrchtung nur auf diese Informationen zugreifen, wenn sie eine Vorwärts- oder Rückwärtssuche ausführt. Die Datengröße von Audiodaten mit einer Abspieldauer von 2 s hängt von der Bitrate ab, die verwendet wird, wenn die Audiodaten abgespielt werden. Wie bereits festgestellt worden ist, wird eine Bitrate in einem Bereich von 16 Kbps bis 144 Kbps verwendet, sodass die Datenmenge, die in 2 s abgespielt wird, in einem Bereich zwischen 4 KB (= 16 Kbps × 2/8) bis 36 KB (= 144 Kbps × 2/8) liegt. Da die innerhalb von 2 s abgespielte Datenmenge in einem Bereich von 4 KB bis 36 KB liegt, muss die Datenlänge jedes Eintrages in der Zeitsuchtabelle zum Schreiben der Datenlänge von Audiodaten eine Länge von 2 Byte (= 16 Bit) aufweisen. Dies rührt da her, dass ein 16 Bit umfassender Wert eine Zahl in dem Bereich von 0 bis 64 KB darstellen kann.
Wenn demgegenüber beispielsweise die Gesamtdatengröße der Zeitsuchtabelle auf 504 Byte beschränkt wird (was einer Datengröße von TKTMSRT entspricht, die nachstehend noch beschrieben wird), so kann die Maximalzahl von Einträgen in der Zeitsuchtabelle gemäß 504/2 = 252 berechnet werden.
Da ein Eintrag alle 2 s bereitgestellt wird, ist die Abspielzeit entsprechend diesem Maximum von 252 Einträgen gleich 504 s (= 2 s × 252) oder 8 min und 24 s (= 8,4 min). Dies bedeutet, dass das Einstellen der maximalen Abspieldauer für einen AOB_BLOCK auf 8,4 min die Datengröße der Zeitsuchtabelle auf 504 Byte begrenzt.
{3-3_10-9} Betrachtungen zu AOBs
Dies beschließt die Beschreibung von AOB_BLOCKs. Nachstehend werden AOBs beschrieben.
Die auf der zweiten Ebene von 10 gezeigten AOBs sind Bereiche, die an jedem Ende ungültige Gebiete aufweisen. Nur ein AOB ist in jeder AOB-Datei vorhanden.
Die ungültigen Gebiete sind Bereiche, die zusammen mit AOB_BLOCKs gelesen und geschrieben und in denselben Clustern wie die AOB_BLOCKs gespeichert werden. Die Anfangs- und Endposition von AOB_BLOCKs innerhalb eines AOB sind durch in den Navigationsdaten enthaltene BITs gezeigt. Die BITs werden in dieser Beschreibung nachstehend noch detailliert erläutert.
Dies beendet die Erläuterung dessen, welche Daten in einer AOB-Datei gespeichert sind. Nachfolgend wird beschrieben, welche Art von Inhalten abgespielt wird, wenn die acht AOBs und AOB_BLOCKs, die in der AOB-Datei von 9 gezeigt sind, aufeinanderfolgend gelesen werden.
{3-3_10-10_16}
16 zeigt den Abspielinhalt, wenn die AOBs und AOB_BLOCKs in dieser AOB-Datei aufeinanderfolgend (sukzessiv) gelesen werden. Die erste Ebene in 16 zeigt die acht AOB-Dateien in dem Anwenderbereich, während die zweite Ebene die acht AOBs zeigt, die in diesen AOB-Dateien aufgezeichnet sind. Die dritte Ebene zeigt die in diesen AOBs enthaltenen AOB_BLOCKs.
Die fünfte Ebene zeigt die Titel von fünf Inhalten, die von diesen AOB-Dateien gebildet werden. In diesem Beispiel entsprechen die „Inhalte" (contents) den fünf Liedern SongA, SongB, SongC, SongD und SongE, während der „Titel" (title) einem Musikalbum entspricht, das sich aus diesen fünf Liedern zusammensetzt. Die gestrichelten Linien AS1, AS2, AS3, ..., AS7 und AS8 zeigen die Entsprechung zwischen den AOB_BLOCKs und denjenigen Teilen, in die das Album unterteilt ist, weshalb die vierte Ebene in 16 die Einheiten zeigt, die zur Unterteilung des auf der fünften Ebene gezeigten Musikalbums verwendet werden.
Bei Betrachtung der gestrichelten Linien ergibt sich, dass der in AOB#1 enthaltene AOB_BLOCK ein Lied (SongA) mit einer Abspieldauer von 6,1 min ist. Der in AOB#2 enthaltene AOB_BLOCK ist ein Lied (SongB) mit einer Abspieldauer von 3,3 min. Der in AOB#3 enthaltene AOB_BLOCK ist ein Lied (SongC) mit einer Abspieldauer von 5,5 min. Auf diese Weise entsprechen „AOB001.SA1" bis „AOB003.SA1" jeweils einem anderen Lied. Die sechste Ebene von 16 ist eine Spursequenz, die sich aus Spuren TrackA bis TrackE zusammensetzt. Diese Spuren TrackA bis TrackE entsprechen den fünf Liedern SongA, SongB, SongC, SongD und SongE und werden jeweils als eigene Abspieleinheiten behandelt.
Demgegenüber weist AOB#4 eine Abspieldauer von 8,4 min auf und ist der erste Teil (oder „Kopfteil") des Liedes SongD, das eine Abspieldauer von 30,6 min aufweist. Die in AOB#5 und AOB#6 enthaltenen AOB_BLOCKs sind Mittelteile des Liedes SongD und weisen ebenfalls Abspieldauern von 8,4 min auf. Der in AOB#7 enthaltene AOB_BLOCK ist der Endteil des Liedes SongD und weist eine Abspieldauer von 5,4 min auf. Auf diese Weise wird ein Lied, das eine Gesamtabspieldauer von 30,6 min aufweist, in (8,4 + 8,4 + 8,4 + 5,4 min dauernde) Teile unterteilt, die jeweils in einem anderen AOB enthalten sind. Aus 16 ist ersichtlich, dass jedes in einer AOB-Datei enthaltene Lied zwangsweise eine maximale Abspieldauer von 8,4 min aufweist.
Die Erläuterung macht deutlich, dass das Begrenzen der Abspieldauern von AOBs gemäß vorstehender Beschreibung die Datengröße der Zeitsuchtabelle entsprechend jedem AOB beschränkt. Nachfolgend werden die in jeder Zeitsuchtabelle enthaltenen Navigationsdaten beschrieben.
{3-3_8A,B-2}
Die Navigationsdaten setzen sich aus den beiden Dateien „SD_Audio.PLM" und „SD_Audio.TKM" zusammen, die bereits erwähnt worden sind. Die Datei „SD_Audio.PLM" enthält den Spiellistenverwalter (PlaylistManager), während die Datei „SD_Audio.TKM" den Spurverwalter (TrackManager) enthält.
Wie bereits als Teil der Erläuterung der Präsentationsdaten ausgeführt worden ist, speichert eine Vielzahl von AOB-Dateien codierte AOBs, wobei jedoch keine weiteren Informationen, so beispielsweise die Abspieldauer der AOBs, die Namen der von den AOBs dargestellten Lieder und die Credits für den Liedschreiber beziehungsweise die Liedschreiber, angegeben sind. Während eine Vielzahl von AOBs in einer Vielzahl von AOB-Dateien aufgezeichnet ist, ist kein Hinweis bezüglich der Abspielreihenfolge der AOBs gegeben. Zur Bereitstellung einer derartigen Information für die Abspielvorrichtung sind der Spurverwalter (TrackManager) und der Spiellistenverwalter (PlaylistManager) vorhanden.
Der Spurverwalter zeigt die Entsprechung zwischen den in den AOB-Dateien aufgezeichneten AOBs und den Spuren und enthält eine Vielzahl von Stücken bzw. Elementen von Spurverwaltungsinformationen, die jeweils eine Vielzahl von Informationen angeben, so beispielsweise die Abspieldauer von AOBs sowie die Liednamen und die Liedschreiber von verschiedenen AOBs.
In der vorliegenden Beschreibung bezeichnet der Begriff „Spur" (Track) eine bedeutungstragende Abspieleinheit für Anwender, wobei bei Speicherung von urheberrechtlich geschützter Musik auf einer Flashspeicherkarte 31 jedes Lied eine eigene Spur innehat. Wird demgegenüber ein „Hörbuch" (audiobook) (das heißt urheberrechtlich geschützte Literatur, die in Form einer aufgezeichneten Einlesung gespeichert ist) auf einer Flashspeicherkarte 31 gespeichert, so kann jedes Kapitel oder jeder Absatz als eigene Spur gespeichert sein. Der Spurverwalter ist vorgesehen, um eine Vielzahl von AOBs zu verwalten, die in einer Vielzahl von AOB-Dateien aufgezeichnet sind, und zwar als Gruppe von Spuren.
Eine Spielliste (Playlist) stellt die Abspielreihenfolge einer Vielzahl von Spuren ein. Eine Vielzahl von Spiellisten kann in dem Spiellistenverwalter enthalten sein.
Nachfolgend wird der Spurverwalter unter Bezugnahme auf die Zeichnung beschrieben.
{17-1_18} Details der Zusammensetzung des Spiellistenverwalters und des Spurverwalters
17 zeigt detailliert die Zusammensetzung des Spiellistenverwalters und des Spurverwalters bei diesem Ausführungsbeispiel in Form einer Hierarchie. 18 zeigt die Größen des Spiellistenverwalters und des Spurverwalters. Die rechte Seite von 17 zeigt die Elemente auf der linken Seite detaillierter, und zwar als gestrichelte Linien, die angeben, welche Elemente detaillierter gezeigt werden.
Wie in 17 gezeigt ist, setzt sich der Spurverwalter aus den Spurinformationen (TKI) #1, #2, #3, #4, ..., #n zusammen, wie durch die gestrichelte Linie h1 gezeigt ist. Diese TKIs sind Informationen zum Verwalten der AOBs aus der Aufzeichnung in AOB-Dateien als Spuren und entsprechen jeweils einer anderen AOB-Datei. Aus 17 ist ersichtlich, dass sich jede TKI aus Track General Information (TKGI), Track_Text_Information (TKTXTI_DA), in die exklusiv Textinformationen in eine Spur geschrieben werden können, und Track_Time_Search_Table (TKTMSRT), die als Zeitsuchtabelle dient, zusammensetzt.
Aus 18 ist ersichtlich, dass jede TKI eine feste Größe von 1024 Byte aufweist, was bedeutet, dass die Gesamtgröße von TKGI und TKTXTI_DA bei 512 Byte festgelegt ist, was wiederum daher rührt, dass die Größe von TKTMSRT fest bei 512 Byte liegt. In dem Spurverwalter kann eine Gesamtzahl von 999 TKIs eingestellt werden.
Wie durch die gestrichelte Linie h3 gezeigt ist, setzt sich TKTMSRT aus TMSRT_Header und TMSRT_entries (TMSRT_Einträgen) zusammen.
{17-2_19} Entsprechung von TKI mit AOB-Dateien und AOBs
19 zeigt, wie die TKIs, die in 17 gezeigt sind, den AOB-Dateien und den AOBs in 16 entsprechen. Die Kästen auf der ersten Ebene von 19 zeigen eine Sequenz von Spuren, die sich aus den Spuren TrackA bis TrackE zusammensetzen. Der große Rahmen auf der zweiten Ebene zeigt den Spurverwalter, während die dritte und vierte Ebene die in 16 gegebenen acht AOB-Dateien zeigen. Die acht AOB-Dateien sind in den in 16 gezeigten acht AOBs aufgezeichnet und bilden ein Musikalbum, das die Spuren TrackA, TrackB, TrackC, TrackD und TrackE enthält. Die zweite Ebene zeigt die acht TKIs. Die Zahlen „1", „2", „3", „4", die jeder TKI zugewiesen sind, sind die Seriennummern, die zur Identifizierung jeder TKI verwendet werden, wobei jede TKI einer AOB-Datei entspricht, an die dieselbe Seriennummer 001, 002, 003, 004, 005, ... vergeben worden ist.
Eingedenk dessen ist aus 19 ersichtlich, dass TKI#1 der Datei „AOB001.SA1", TKI#2 der Datei „AOB002.SA1", TKI#3 der Datei „AOB003.SA1" und TKI#4 der Datei „AOB004.SA1" entsprechen. Die Entsprechung zwischen TKIs und AOB_FRAMEs ist durch die Pfeile TA1, TA2, TA3, TA4, ... in 19 gezeigt.
Auf diese Weise entspricht jede TKI einem anderen AOB, das in einer AOB-Datei aufgezeichnet ist, und gibt detaillierte Informationen, die nur für das entsprechende AOB Gültigkeit haben.
{17-3_20} Datenzusammensetzung von TKTMSRT
Nachfolgend werden diejenigen Informationen beschrieben, die für einzelne in AOB-Dateien aufgezeichnete AOBs Gültigkeit haben, und zwar beginnend mit TKTMSRT. 20 zeigt die Zusammensetzung der Daten von TKTMSRT im Detail.
Die rechte Seite von 20 zeigt detailliert die Datenzusammensetzung des Zeitsuchtabellenheaders (TMSRT_Header). In 20 weist der TMSRT_Header eine Datengröße von 8 Byte auf und besteht aus drei Feldern. Die ersten zwei Byte sind eine TMSRT_ID (TMSRT-Kennung), die nächsten beiden Byte sind reserviert und die letzten vier Byte sind „Total TMSRT_entry Number".
Eine eindeutige Kennung (ID) zum Identifizieren von TMSRT ist in „TMSRT_ID" aufgezeichnet. Die Gesamtzahl von TMSRT_Einträgen in TMSRT ist in Total TMSRT_entry Number aufgezeichnet.
{17-3_21-1} Spezifisches Beispiel für TKTMSRT
Nachfolgend wird TKTMSRT detailliert beschrieben. 21 zeigt ein Beispiel für TKTMSRT. Die linke Seite von 21 zeigt ein AOB, wohingegen die rechte Seite TKTMSRT in Entsprechung hierzu zeigt. Das AOB auf der linken Seite von 21 setzt sich aus einer Vielzahl von AOB_ELEMENTs zusammen, die mit #1, #2, #3, ... #n nummeriert sind, die Bereiche mit den Nummern AR1, AR2, AR3, ..., ARn zur Rechten belegen.
Zahlen wie „0", „32000", „64200", „97000", „1203400" und „124000" zeigen die Relativadressen von Gebieten AR1, AR2, AR3, ARn-1, die von AOB_ELEMENTs bezüglich des Anfangs von AOB_BLOCK belegt sind. So ist beispielsweise AOB_ELEMENT#2 an einer Position aufgezeichnet, die in einem Abstand „32000" vom Anfang von AOB_BLOCK befindlich ist, während AOB_ELEMENT#3 an einer Position aufgezeichnet ist, die in einem Abstand „64200" vom Anfang von AOB_BLOCK aufgezeichnet ist und AOB_ELEMENT#n-1 an einer Position aufgezeichnet ist, die in einem Abstand „1203400" vom Anfang von AOB_BLOCK befindlich ist.
Man beachte, dass der Abstand zwischen jedem belegten Bereich und dem Anfang von AOB_BLOCK kein Vielfaches eines bestimmten Wertes ist, was bedeutet, dass die von AOB_ELEMENTs belegten Bereiche nicht dieselbe Größe aufweisen. Der Grund dafür, dass belegte Bereiche unterschiedliche Größen aufweisen, liegt darin, dass jeweils unterschiedliche Datenmengen zur Codierung von AOB_FRAME verwendet werden.
Da die Größe des von jedem AOB belegten Bereiches variiert, ist es notwendig, die Abspielvorrichtung vorab über die Position von jedem AOB_ELEMENT in einem AOB bei Ausführung eines Sprunges an den Anfang von AOB_ELEMENT in Kenntnis zu setzen. Zu diesem Zweck sind eine Vielzahl von TMSRT_entries (TMSRT_Einträgen) in TKTMSRT gegeben. Die Pfeile RT1, RT2, RT3, ..., RTn-1 zeigen die Entsprechung zwischen den Bereichen AR1, AR2, AR3, ..., ARn-1, die jeweils von jedem AOB_ELEMENT und TMSRT_entry#1, TMSRT_entry#2, TMSRT_entry#3, ..., TMSRT_entry#n-1, TMSRT_entry#n belegt werden. Mit anderen Worten, die Größe des Bereiches AR1, der von AOB_ELEMENT#1 belegt ist, wird in TMSRT_entry#1 geschrieben, während die Größen der Bereiche AR2 und AR3, die von AOB_ELEMENT#2 und AOB_ELEMENT#3 belegt sind, in TMSRT_entry#2 und in TMSRT_entry#3 geschrieben werden.
Da das belegte Gebiet AR1 den Bereich vom Anfang des AOB zum Anfang von AOB_ELEMENT#2 „32000" einnimmt, wird die Größe „32000" (= 32000 – 0) in TMSRT_entry#1 geschrieben. Das belegte Gebiet AR2 nimmt den Bereich vom Anfang von AOB_ELEMENT#2 „32000" zum Anfang von AOB_ELEMENT#3 „64200" ein, sodass die Größe „32200" (= 64200 – 32000) in TMSRT_entry#2 geschrieben wird. Das belegte Gebiet AR3 nimmt den Bereich vom Anfang von AOB-ELEMENT#3 „64200" zum Anfang von AOB_ELEMENT#4 „97000" ein, sodass die Größe „32800" (= 97000 – 64200) in TMSRT_entry#3 geschrieben wird. Analog nimmt das belegte Gebiet ARn-1 den Bereich vom Anfang von AOB_ELEMENT#n-1 „1203400" zum Anfang von AOB_ELEMENT#n „124000" ein, sodass die Größe „36600" (= 1240000 – 1203400) in TMSRT_entry#n-1 geschrieben wird.
{17-3_21-2} Wie TKTMSRT gelesen wird
Auf diese Weise werden die Datengrößen von AOB_ELEMENTs in eine Zeitsuchtabelle geschrieben. Da die Datenlänge von jedem AOB_BLOCK jeweils auf ein Maximum von 8,4 min beschränkt ist, ist die Gesamtzahl von AOB_ELEMENTs, die in einem einzelnen AOB enthalten ist, auf eine vorgegebene Zahl (252, wie in 20 gezeigt ist) oder weniger begrenzt. Da die Zahl von AOB_ELEMENTs begrenzt ist, ist auch die Zahl von TMSRT_entries entsprechend AOB_ELEMENTs begrenzt, wodurch die Größe von TKTMSRT, die diese TMSRT_entries enthalten, auf eine vorgegebene Größe be schränkt wird. Da die Größe von TKTMSRT beschränkt ist, kann die Abspielvorrichtung TKIs auf die nachfolgende Weise lesen und verändern.
Die Abspielvorrichtung liest ein bestimmtes AOB, und mit dem Beginn des Abspielens liest sie die entsprechende TKI und speichert sie in einem Speicher. Die entsprechende TKI wird in dem Speicher vorgehalten, während das Abspielen dieses AOB andauert. Sobald das Abspielen des AOB endet, wird das nachfolgende AOB gelesen, und wenn das Abspielen dieses AOB beginnt, schreibt die Abspielvorrichtung die TKI entsprechend diesem nachfolgenden AOB in den Speicher an die Stelle der alten TKI. Diese nächste TKI wird in dem Speicher vorgehalten, während das Abspielen des nachfolgenden AOB andauert.
Durch auf diese Weise erfolgendes Lesen und Speichern von TKIs kann die notwendige Speicherkapazität in der Abspielvorrichtung minimiert werden, während diese immer noch in der Lage ist, Spezialabspielfunktionen, so beispielsweise eine Vorwärts- und Rückwärtssuche, bereitzustellen. Während beim vorliegenden Ausführungsbeispiel derjenige Fall beschrieben ist, in dem die Datenlänge von der ersten Adresse von AOB_ELEMENT zu der ersten Adresse des nächsten AOB_ELEMENT in TMSRT_entry geschrieben wird, können anstatt dessen auch Relativadressen vom Anfang von AOB_BLOCK zu den ersten Adressen von AOB_ELEMENTs geschrieben werden.
{17-3_21-3} Spezifizierung eines Clusters, das AOB_ELEMENT enthält
Nachfolgend wird beschrieben, wie AOB_ELEMENT unter Verwendung von TKTMSRT gelesen werden kann. TKTMSRT enthält die Größe von jedem AOB_ELEMENT, sodass wenn AOB_ELEMENT#y, das das y-te AOB_ELEMENT vom Anfang von AOB ist, gelesen werden soll, das Cluster u, das der nachstehend angegebenen Gleichung 1 genügt, berechnet wird, und die Daten, die mit dem Offset v vom Anfang des Clusters u positioniert sind, gelesen werden.
Gleichung 1

Cluster u = (Gesamtzahl von TMSRT entries von AOB_ELEMENT#1 bis AOB_ELEMENT#y-1 + DATA offset)/Clustergröße
Offset v = (Gesamtzahl von TMSRT-entries von AOB_ELEMENT#1 bis AOB_ELEMENT#y-1 + DATA offset) mod Clustergröße

Hierbei gibt c = a mod b an, dass c der Rest ist, der sich ergibt, wenn a durch b geteilt wird.
DATA_Offset wird in BIT geschrieben und ist in der vorliegenden Beschreibung nachfolgend noch erläutert.
{17-4} TKTXI_DA
Dies beendet die Erläuterung der Zeitsuchtabelle (TKTMSRT). Nachfolgend wird das in dem oberen Teil von TKTMSRT aufgezeichnete Track_Text_Information Data Area (TKTXI_DA) beschrieben.
Track_Text_Information Data Area (TKTXI_DA) wird zur Speicherung von Textinformationen verwendet, die den Namen des Künstlers, den Namen des Albums, den Mischer, den Produzenten und andere derartige Informationen zeigen. Dieser Bereich wird auch dann zur Verfügung gestellt, wenn derartige Textinformationen überhaupt nicht vorhanden sind.
{17-5} TKGI
Nachfolgend wird TKGI aus der Aufzeichnung in dem oberen Bereich von TKTXI_DA beschrieben. In 17 gezeigt sind mehrere Sätze von Informationen, die gezeigt sind als: die Kennung „TKI_ID" von TKI, die TKI-Nummer „TKIN", die TKI-Größe „TKI_SZ", ein Verknüpfungszeiger „TKI_LNK_PTR" auf die nächste TKI, Blockattribute „TKI_BLK_ATR", eine Abspieldauer „TKI_PB_TM", die Audioattribute „TKI_AOB_ATR", und Blockinformationen BIT. Man beachte, dass ein Teil dieser Informationen in 17 gezeigt ist, um die Darstellung zu vereinfachen.
{17-5_22-1} TKGI
Nachfolgend wird die Zusammensetzung von TKGI im Detail unter Bezugnahme auf 22 beschrieben. Der Unterschied zwischen 17 und 22 besteht darin, dass die Datenzusammensetzung von TKGI gemäß Darstellung in 17 auf der linken Sei te dieser Figur angeordnet ist und die Bitzusammensetzungen von „TKI_BLK_ATR", „TKI_AOB_ATR" und „ISRC" deutlich gezeigt sind.
[17-5_22-2} TKI_ID
Eine eindeutige Kennung (ID) für TKI wird in „TKI_ID" geschrieben. Beim vorliegenden Ausführungsbeispiel wird ein 2 Bit umfassender „A4"-Code verwendet.
{17-5_22-3} TKI_ID
Eine TKI-Nummer im Bereich von 1 bis 999 wird in „TKIN" geschrieben. Man beachte, dass TKIN für jede TKI eindeutig ist. Beim vorliegenden Ausführungsbeispiel wird die Position jeder TKI in dem Spurverwalter als TKIN verwendet. Dies bedeutet, dass „1" als TKI-Nummer von TKI#1, „2" als TKI-Nummer von TKI#2 und „3" als TKI-Nummer von TKI#3 geschrieben werden.
{17-5_22-4} TKI_SZ
Die Datengröße von TKI in Byteeinheiten wird in „TKI_SZ" geschrieben. Gemäß 22 sind 1024 Byte als Datengröße von TKI gegeben, sodass jede TKI beim vorliegenden Ausführungsbeispiel eine Länge von 1024 Byte aufweist.
{17-5_22-4} TKI_LNK_PTR
Die TKIN derjenigen TKI, mit der die aktuelle TKI verknüpft ist, wird in TKI_LNK_PTR geschrieben. Nachfolgend werden derartige Verknüpfungen zwischen TKIs beschrieben.
Setzt sich eine Spur aus einer Vielzahl von AOBs zusammen, die in einer Vielzahl von AOB-Dateien aufgezeichnet sind, so werden diese AOB-Dateien als einzelne Spuren durch Verknüpfen der Vielzahl von TKIs verwaltet, die diesen AOB-Dateien entsprechen. Zum Verknüpfen einer Vielzahl von TKIs ist es notwendig, die TKI der AOB-Datei zu zeigen, die auf die AOB-Datei der aktuellen TKI folgt. Entsprechend wird TKIN von TKI, das auf die aktuelle TKI folgt, in TKI_LNK_PTR geschrieben.
{17-5_22-6_19} TKI_LNK_PTR
Nachfolgend werden die Einstellungen beschrieben, die für TKI_LNK_PTR in den acht TKIs, wie in 19 gezeigt ist, gemacht werden. Die Spurinformationen mit den Nummern #1 bis #3 und #8 entsprechen jeweils eigenen Spuren, sodass keine Informationen in dem zugehörigen TKI_LNK_PTR eingestellt sind. Die Spurinformationen TKI#4, TKI#5, TKI#6, TKI#7 entsprechen den vier AOB-Dateien, die TrackD bilden, sodass die nächsten Spurinformationen in dem TKI_LNK_PTR dieser TKIs angezeigt wird. Wie durch Pfeile TL4, TL5 und TL6 in 19 gezeigt ist, werden „TKI#5" in TKI_LNK_PTR von TKI#4, „TKI#6" in TKI_LNK_PTR von TKI#5 und „TKI#7" in TKI_LNK_PTR von TKI#6 eingestellt.
Im Ergebnis kann die Abspielvorrichtung auf TKI_LNK_PTR gemäß Vorlage in den TKIs entsprechend diesen vier AOB-Dateien Bezug nehmen und so herausfinden, dass die vier TKIs TKI#4 bis TKI#7 und die vier AOB-Dateien „AOB004.SA1" bis „AOB007.SA1" eine einzelne Spur, nämlich TrackD bilden.
{17-5_22-7} TKI_BLK_ATR
Die Attribute der aktuellen TKI werden in „TKI_BLK_ATR" geschrieben. Wie in 22 gezeigt ist, zeigen die Informationen, die innerhalb der gestrichelten Linien gezeigt sind, die sich von TKI_BLK_ATR aus erstrecken, die Bitzusammensetzung von TKI_BLK_ATR. In 22 ist TKI_BLK_ATR als 16 Bit umfassend gezeigt, wobei die Bits von Bit b3 bis b15 für zukünftige Verwendungszwecke reserviert sind. Die drei Bits von Bit b2 bis b0 werden verwendet, um die Attribute von TKI zu zeigen.
Entspricht eine TKI einer vollständigen Spur, so wird der Wert „00b" in TKI_BLK_ATR geschrieben (Diese Einstellung wird nachstehend als „Track" bezeichnet. Entsprechen mehrere TKIs derselben Spur, so wird der Wert „001b" in TKI_BLK_ATR der ersten TKI geschrieben (Diese Einstellung wird nachstehend als „Head_of_Track" bezeichnet). Der Wert „010b" wird in TKI_BLK_ATRs von TKIs entsprechend AOBs in der Mitte der Spur geschrieben (Diese Einstellung wird nachstehend als „Midpoint_of_Track "bezeichnet). Der Wert „011b" wird in TKI_BLK_ATR von TKI entsprechend dem AOB am Ende der Spur (Diese Einstellung wird nachstehend als „End_of_Track bezeichnet) geschrieben. Wird eine TKI nicht verwendet, existiert jedoch ein TKI-Bereich, das heißt, ist eine gelöschte TKI vorhanden, so wird der Wert „100b" in TKI_BLK_ATR geschrieben (Diese Einstellung wird nachstehend als „nicht verwendet" bezeichnet). Wird eine TKI nicht ver wendet und ist kein TKI_Bereich vorhanden, so wird der Wert „101b" in TKI_BLK_ATR geschrieben.
{17-5_22-8_19} Einstellungsbeispiele für TKI_BLK_ATR
Nachfolgend werden die Einstellungen von TKI_BLK_ATR für jede TKI bei dem in 19 gezeigten Beispiel beschrieben.
Durch Bezugnahme auf TKI_BLK_ATR jeder TKI ist ersichtlich, dass die vier Paare TKI#1 („AOB001.SA1"), TKI#2 („AOB002.SA1"), TKI#3 („AOB003.SA1") und TKI#8 („AOB008.SA1") jeweils eigenen Spuren entsprechen, da TKI_BLK_ATR von jedem TKI#1, TKI#2, TKI#3 und TKI#8 als „Track" eingestellt ist.
TLK_BLK_ATR von TKI#4 wird auf „Head_of_Track" eingestellt, TLK_BLK_ATR von TKI#7 wird auf „End_of_Track" eingestellt, und TLK_BLK_ATR von TKI#5 und TKI#6 wird auf „Midpoint_of_Track" eingestellt. Dies bedeutet, dass die AOB-Datei („AOB004.SA1") entsprechend TKI#4 den Anfang einer Spur bildet, die AOB-Dateien („AOB005.SA1") und („AOB006.SA1") entsprechend TKI#5 und TKI#6 mittlere Punkte der Spur bilden, während die AOB-Datei („AOB007.SA1") entsprechend TKI#7 das Ende einer Spur bildet.
Durch Klassifizieren der Kombinationen von TKI und der entsprechenden AOB-Datei entsprechend den Einstellungen von TKI_BLK_ATR in TKI wird ersichtlich, dass die Kombination aus TKI#1 und „AOB001.SA1" eine erste Spur (TrackA) bilden. Analog bildet die Kombination aus TKI#2 und „AOB002.SA1" eine zweite Spur (TrackB) und die Kombination aus TKI#3 und „AOB003.SA1" eine dritte Spur (TrackC). Die Kombination aus TKI#4 und „AOB004.SA1" bildet den ersten Teil der vierten Spur (TrackD), die Kombinationen aus TKI#5 und „AOB005.SA1" sowie TKI#6 und „AOB006.SA1" bilden mittlere Teile von TrackD, und die Kombination aus TKI#7 und „AOB007.SA1" bildet den Endteil von TrackD. Schließlich bildet die Kombination von TKI#8 und „AOB008.SA1" einen fünften Track (TrackE).
{17-5_22-9} TKI_PB_TM
Die Abspieldauer der Spur (Lied), die aus den AOBs zusammengesetzt ist, die in der AOB-Datei entsprechend einer TKI gespeichert sind, wird in „TKI_PB_TM" in TKI geschrieben.
Setzt sich eine Spur aus einer Vielzahl von TKIs zusammen, so wird die gesamte Abspieldauer der Spur in TKI_PB_TM der ersten TKI entsprechend der Spur geschrieben, während die Abspieldauer des entsprechenden AOB in die zweiten und nachfolgenden TKIs für die Spur geschrieben wird.
{17-5_22-10} TKI_AOB_ATR
Die Codierbedingungen, die bei der Erzeugung eines AOB verwendet werden, das heißt, Informationen wie beispielsweise (1) die Abtastfrequenz, mit der das AOB, das in der entsprechenden AOB-Datei aufgezeichnet worden ist, abgetastet wird, (2) die Übertragungsbitrate und (3) die Anzahl von Kanälen werden in „TKI_AOB_ATR" in einer TKI geschrieben. Die Bitzusammensetzung von TKI_AOB_ATR ist innerhalb der gestrichelten Linien gezeigt, die sich in 22 von „TKI_AOB_ATR" aus erstrecken.
In 22 setzt sich TKI_AOB_ATR aus 32 Bit zusammen, wobei die Codierungsart in das 4 Bit umfassende Feld von Bit b16 bis Bit b19 geschrieben ist. Ist das AOB entsprechend MPEG-2 AAC codiert (mit einem ADTS-Header), so wird der Wert „0000b" in dieses Feld geschrieben, während bei einer Codierung des AOB entsprechend MPEG-Layer3 (MP3) der Wert „0001b" eingeschrieben wird. Ist das AOB entsprechend Windows Media Audio (WMA) codiert, so wird der Wert „0010b" in dieses Feld geschrieben.
Die bei der Codierung des AOB verwendete Bitrate wird in das 8 Bit umfassende Feld zwischen Bit b15 und Bit b8 geschrieben. Ist das AOB entsprechend MPEG-2 AAC (mit einem ADTS-Header) codiert, so wird ein Wert zwischen „16" und „72" in dieses Feld geschrieben, während bei einer Codierung des AOB entsprechend MPEG1-Layer3 (MP3) ein Wert zwischen „16" und „96" eingeschrieben wird. Ist das AOB entsprechend MPEG1-Layer3 LSF (MP3) codiert, so wird ein Wert zwischen „16" und „80" in dieses Feld geschrieben, während bei einer Codierung des AOB entsprechend Windows Media Audio (WMA) ein Wert zwischen „8" und „16" eingeschrieben wird.
Die Abtastfrequenz, die bei der Codierung des AOB verwendet wird, wird in das 4 Bit umfassende Feld zwischen Bit b7 und Bit B4 geschrieben. Ist die Abtastfrequenz gleich 48 kHz, so wird der Wert „000b" in dieses Feld geschrieben. Ist die Abtastfrequenz gleich 44,1 kHz, so wird der Wert „0001b" eingeschrieben, ist die Abtastfrequenz gleich 32 kHz, so wird der Wert „0010b" eingeschrieben, ist die Abtastfrequenz gleich 24 kHz, so wird der Wert „0011b" eingeschrieben, ist die Abtastfrequenz gleich 22,05 kHz, so wird der Wert „0100b" eingeschrieben, und ist die Abtastfrequenz gleich 16 kHz, so wird der Wert „0101b" eingeschrieben.
Die Anzahl der Kanäle wird in das 3 Bit umfassende Feld von Bit b3 bis Bit b1 geschrieben. Wenn ein Kanal verwendet wird (mono), so wird der Wert „000b" in dieses Feld geschrieben, wohingegen bei Verwendung von zwei Kanälen (das heißt stereo) der Wert „001b" in dieses Feld geschrieben wird.
Das 12 Bit umfassende Feld von Bit b31 bis Bit b20 ist für eine zukünftige Verwendung reserviert, genauso wie das Bit b0.
{17-5_22-11} ISRC
ISRC (International Standard Recording Code ISRC, internationaler Standardaufnahmecode) wird in TKGI geschrieben. In 22 zeigen die gestrichelten Linien, die sich von dem „ISRC"-Kasten aus erstrecken, den Inhalt von ISRC. Wie in der Zeichnung dargestellt ist, setzt sich ISRC aus zehn Byte zusammen, wobei ein Recording-Item-Code (#12) (Aufzeichnungsgegenstandscode) in das 4 Bit umfassende Feld zwischen Bit b4 und Bit b7 geschrieben wird. Ein Recording-Code/Recording-Item-Code (#11) wird in das 4 Bit umfassende Feld zwischen Bit b8 und Bit b11 geschrieben.
Ein Recording-Code (Aufzeichnungscode) (ISRC #10, #9, #8) wird in das 12 Bit umfassende Feld zwischen Bit b12 und Bit b23 geschrieben. Ein Year-of-Recording-Code (Jahr der Aufzeichnung) wird in das 8 Bit umfassende Feld zwischen Bit b24 und Bit b31 geschrieben.
Der First-Owner-Code (erster Eigentümer) (ISRC #3, #4, #5) wird in das 6 Bit umfassende Feld zwischen Bit b32 und Bit b37, das 6 Bit umfassende Feld zwischen Bit b40 und Bit b45 und das 6 Bit umfassende Feld zwischen Bit b48 und Bit b53 geschrieben. Der Country-Code (Land) (ISRC #1, #2, #3) wird in das 6 Bit umfassende Feld zwischen Bit b56 und Bit b61 und in das 6 Bit umfassende Feld zwischen Bit b64 und Bit b69 geschrieben. Ein 1-Bit-Gültigkeitsmerker (validity flag) wird in ein 1 Bit umfassendes Feld geschrieben, das von Bit b79 gebildet wird. Eine detaillierte Beschreibung von ISRC findet sich bei IS03901:1986 „Documentation-International Standard Recording Code (ISRC)".
{17-5_22-12_23A-1} BIT
Die „Blockinformationstabelle (block information table) (BIT)" ist eine Tabelle zum Verwalten von AOB_BLOCK. Ihre Zusammensetzung ist detailliert in 23A und 23B beschrieben.
Wie in 23A gezeigt ist, umfasst BIT ein DATA_OFFSET-Feld, das einen Bereich vom 60. Byte zum 63. Byte belegt, ein SZ_DATA-Feld, das einen Bereich vom 64. Byte zum 67. Byte belegt, ein TMSRTE_Ns-Feld, das einen Bereich vom 68. Byte zum 71. Byte belegt, ein FNs_1st_TMSRTE-Feld, das einen Bereich vom 72. Byte zum 73. Byte belegt, ein FNs_Last_TMSRTE-Feld, das einen Bereich vom 74. Byte zum 75. Byte belegt, einen FNS_Middle_TMSRTE-Feld, das einen Bereich vom 76. Byte zum 77. Byte belegt, und ein TIME_LENGTH-Feld, das einen Bereich vom 78. Byte zum 79. Byte belegt.
Jedes dieser Felder werden nachstehend detailliert beschrieben.
{17-5_22-12_23A-2} DATA_Offset
Die Relativadresse des Anfangs von AOB-BLOCK ab der Grenze zwischen Clustern wird in „DATA_Offset" als in Byteeinheiten gegebener Wert geschrieben. Hierdurch wird die Größe eines ungültigen Gebietes zwischen AOB und AOB_BLOCK ausgedrückt. Als Beispiel sei genannt, dass wenn ein Anwender eine Radiosendung auf einer Flashspeicherkarte 31 als AOBs aufzeichnet und den Einleitungsteil einer Spur, über die der Moderator gesprochen hat, löschen will, DATA_OFFSET in BIT derart eingestellt werden kann, dass die Spur ohne den die Stimme des Moderators enthaltenden Einleitungsteil abgespielt wird.
{17-5_22-12_23A-3} SZ_DATA
Die Datenlänge von AOB_BLOCK in einer Darstellung in Byteeinheiten wird in „SZ_DATA" geschrieben. Durch Abziehen eines Wertes, der sich durch Addieren von SZ_DATA zu DATA_Offset ergibt, von der Dateigröße (ein ganzzahliges Vielfaches der Clustergröße) kann die Größe des ungültigen Gebietes, das auf AOB_BLOCK folgt, ermittelt werden.
{17-5_22-12_23A-4} TMSRTE_Ns
Die Gesamtzahl von TMSRT_Einträgen, die in AOB_BLOCK enthalten ist, wird in „TMSRTE_Ns" geschrieben.
Die Anzahl von AOB_FRAMEs, die in AOB_ELEMENT mit einer Positionierung am Anfang eines aktuellen AOB_BLOCK enthalten ist, wird in „FNs_1st_TMSRTE" geschrieben.
Die Anzahl von AOB_FRAMEs, die in AOB_ELEMENT mit einer Positionierung am Ende eines aktuellen AOB_BLOCK enthalten ist, wird in „FNs_Last_TMSRTE" geschrieben.
Die Anzahl von AOB_FRAMEs, die in jedem AOB_ELEMENT außer denjenigen am Anfang und am Ende eines aktuellen AOB_BLOCK enthalten ist, das heißt, AOB_ELEMENTs in der Mitte von AOB_BLOCK, werden in „FNs_Middle_TMSRTE" geschrieben.
Die Abspieldauer von AOB_ELEMENT wird in dem in 23C gezeigten Format in das „TIME_LENGTH"-Feld beschrieben, und zwar mit einer Genauigkeit in der Größenordnung von Millisekunden. Wie in 23C gezeigt ist, weist das „TIME_LENGTH"-Feld eine Länge von 16 Bit auf. Ist das verwendete Codierverfahren MPEG-ACC oder MPEG-Layer3, so ist die Abspieldauer von AOB_ELEMENT gleich 2 s, weshalb der Wert „2000" in das „TIME_LENGTH"-Feld geschrieben wird.
{17-5_22-13_23B}
23B zeigt die Anzahl von AOB_FRAMEs, die mit „FNs_Middle_TMRTE" bezeichnet ist. Auf dieselbe Weise wie in 14 zeigt 23B die Beziehung zwischen der Ab tastfrequenz (sampling_frequency) und der Anzahl von AOB_FRAMEs, die in einem AOB_ELEMENT in der Mitte von AOB_BLOCK enthalten sind.
Die Beziehung zwischen der Abtastfrequenz (sampling_frequency) und der Anzahl von Frames, die in AOB_ELEMENT enthalten sind, ist, siehe 23B, dieselbe wie die in 14 gezeigte, was bedeutet, dass die Anzahl von Frames in AOB_ELEMENT von der verwendeten Abtastfrequenz abhängt. Die Anzahl der in „FNs_1st_TMSRTE" und „FNs_Last_TMSRTE" geschriebenen Frames ist im Wesentlichen die gleiche wie die in „FNs_Middle_TMSRTE" geschriebene Anzahl, obwohl bei Vorhandensein eines ungültigen Gebietes in AOB_ELEMENT am Anfang und/oder Ende von AOB_BLOCK die in „FNs_1st_TMSRTE" und/oder „FNs_Last_TMSRTE" gegebenen Werte sich vom Wert in „FNs_Middle_TMSRTE" unterscheiden.
{17-5_22-14_24} Beispiel für ein gespeichertes AOB_ELEMENT
24 zeigt die Cluster 007 bis 00E, die das AOB speichern, das sich aus AOB_ELEMENT#1 bis AOB_ELEMENT#4 zusammensetzt. Nachfolgend werden die Einstellungen in BIT beschrieben, wenn ein AOB gemäß Darstellung in 24 gespeichert wird. AOB_ELEMENT#1 bis AOB_ELEMENT#4, die in den Clustern 007 bis 00E gespeichert sind, sind in 24 durch dreieckige Merker bezeichnet, wobei TMSRT_Einträge in TKI jeweils für AOB_ELEMENT#1 bis AOB_ELEMENT#4 eingestellt werden.
In diesem Beispiel ist der erste Teil von AOB_ELEMENT#1 am Anfang von AOB in dem Cluster 007 gespeichert, während der letzte Teil von AOB_ELEMENT#4 am Ende von AOB in dem Cluster 00E gespeichert ist. AOB_ELEMENT#1 bis AOB_ELEMENT#4 belegen den Bereich zwischen md0 in dem Cluster 007 bis md4 in dem Cluster 00E. Wie durch den Pfeil sd1 in 24 gezeigt ist, gibt SZ_DATA in BIT an, dass AOB_ELEMENT#1 bis AOB_ELEMENT#4 einen Bereich vom Anfang des Clusters 007 bis zum Ende des Clusters 00E belegen, weshalb nicht angezeigt ist, dass ungültige Bereiche ud0 und ud1 in den Clustern 007 und 00E vorhanden sind, die nicht von AOB_ELEMENT belegt sind.
Demgegenüber enthält AOB zudem die Teile ud0 und ud1, die in den Clustern 007 und 00E vorhanden sind, jedoch nicht von AOB_ELEMENT#1 oder AOB_ELEMENT#4 belegt sind. DATA_Offset gemäß Angabe in BIT zeigt die Länge des unbelegten Bereiches ud0, also einen Positionswert für den Anfang von AOB_ELEMENT#1 relativ zum Anfang des Clusters 007.
In 24 belegt AOB_ELEMENT#1 einen Bereich von md0 in dem Cluster 007 bis md1 in dem Cluster 008.
AOB_ELEMENT#1 belegt nicht sämtliche Cluster 008, wobei der verbleibende Teil des Clusters von AOB_ELEMENT#2 belegt ist. AOB_ELEMENT#4 belegt einen Bereich von md3 mitten durch das Cluster 00C bis md4 mitten durch das Cluster 00E. Auf diese Weise können AOB_ELEMENTs über Clustergrenzen hinweg gespeichert werden. Mit anderen Worten, AOB_ELEMENTs können ohne Rücksicht auf die Grenzlinien zwischen Clustern aufgezeichnet werden. „FNs_1st_TMSRTE" in BIT zeigt die Anzahl von Frames in AOB_ELEMENT#1 in Anordnung in den Clustern 007 und 008, während „FNs_Last_TMSRTE" in BIT die Anzahl von Frames in AOB_ELEMENT#4 zeigt, die in den Clustern 00C bis 00E angeordnet sind.
Auf diese Weise können AOB_ELEMENTs frei und ohne Rücksicht auf die Grenzen zwischen den Clustern angeordnet werden. BIT stellt Informationen bereit, die den Offset von einer Clustergrenze zu einem AOB_ELEMENT und die Anzahl von Frames in jedem AOB_ELEMENT zeigen.
{17-5_22-14_25} Verwendung der Anzahl von Frames, die in jedem AOB_ELEMENT gegeben sind (Teil 1)
Nachfolgend wird beschrieben, wie die Anzahl von Frames in jedem AOB_ELEMENT gemäß Vorgabe in BIT verwendet wird. Die Anzahl von Frames, die in BIT gegeben ist, wird bei der Durchführung einer Vorwärts- oder Rückwärtssuche verwendet. Wie bereits erläutert worden ist, erfolgt bei derartigen Operationen ein Abspielen von 240 ms von Daten nach einem ersten Überspringen von Daten mit einer Abspieldauer von 2 s.
25 zeigt, wie AOB_FRAME#x+1, das als Nächstes abgespielt werden soll, bei der Durchführung einer Suche mit dem Anfang bei AOB_FRAME#x in einem AOB_ELEMENT#y in AOB eingestellt wird.
25 zeigt denjenigen Fall, in dem ein Anwender eine Vorwärtssuche während des Abspielens von AOB_FRAME#x, das in AOB_FRAME#y enthalten ist, auswählt. In 25 bezeichnen „t" das intermittierende Abspielen (hier für 240 ms), „f(t)" die Anzahl der Frames, die dieser intermittierenden Abspieldauer entsprechen, „skip_time" (Überspringzeit) die Länge der Dauer, die zwischen intermittierenden Abspieldauern übersprungen werden soll (hier 2 s) und „f(skip_time)" die Anzahl von Frames, die der Überspringzeit entsprechen. Das intermittierende Abspielen wird durch Wiederholen der drei nachstehend beschriebenen Prozeduren (1), (2) und (3) erreicht.

(1) Die Abspielvorrichtung bezieht sich auf TMSRT_entry in TKTMSRT und springt an den Anfang des Merkersymbols (AOB_ELEMENT).
(2) Die Abspielvorrichtung nimmt ein Abspielen für 240 ms vor.
(3) Die Abspielvorrichtung springt an den Anfang des nächsten Merkersymbols (AOB_ELEMENT).

AOB_FRAME#x+1, das 2 s + 240 ms von dem in AOB_ELEMENT#y enthaltenen AOB_FRAME#x entfernt ist, ist mit Sicherheit in AOB_ELEMENT#y+1 vorhanden. Beim Spezifizieren von AOB_FRAME#x+1, das 2 s + 240 ms von AOB_FRAME#x entfernt ist, kann die erste Adresse des nächsten AOB_ELEMENT#y+1 unmittelbar durch Lesen von TMSRT_entry aus TKTMSRT berechnet werden, obwohl die Abspielvorrichtung die Anzahl von AOB_FRAMEs ab der Anfangsadresse von AOB_ELEMENT#y+1 bis AOB_FRAME#x+1 aus TMSRT_entry allein nicht ermitteln kann.
Zur Ermittlung dieser Anzahl von AOB_FRAMEs ist es notwendig, die Gesamtzahl von in AOB_ELEMENT#y enthaltenen Frames von dem Gesamtwert von (1) number#x, wodurch die Position von AOB_FRAME#x relativ zum Anfang von AOB_ELEMENT#y gezeigt ist, und (2) f(t) und (3) f(skip_time) abzuziehen. Zur Vereinfachung der Berechnung der relativen Frameposition von AOB_FRAME#x+1 in AOB_ELEMENT#y+1 werden „FNs_1st_TMSRTE", „FNs_Middle_TMSRTE" und „FNs_Last_TMSRTE" für jedes AOB_ELEMENT in BIT geschrieben, wie vorstehend beschrieben worden ist.
{17-5_22-15_26A} Verwendung der Anzahl von Frames, die in jedem AOB_ELEMENT gegeben sind (Teil 2)
Die Anzahl von Frames, die in BIT geschrieben werden, wird auch verwendet, wenn die Abspielvorrichtung eine Zeitsuchfunktion ausführt, bei der das Abspielen an einem Punkt beginnt, der unter Verwendung eines Zeitcodes angegeben ist. 26 zeigt, wie eine Abspielvorrichtung AOB_ELEMENT und AOB_FRAME entsprechend der Abspielanfangszeit, die vom Anwender angegeben wird, spezifizieren kann. Soll das Abspielen zu einer Zeit beginnen, die vom Anwender angegeben ist, so wird die angegebene Zeit (in Sekunden) in dem Jmp Entry-Feld eingestellt, und das Abspielen beginnt ab AOB_ELEMENT#y und einer AOB_FRAME-Position x, die der nachstehend aufgeführten Gleichungen 2 genügen.
Gleichung 2

Jmp_Entry (sec) = (FNs_1st_TMSRTE + FNs_middle_TMSRTE × y + x) × 20 msec

Da „FNs_1st_TMSRTE" und „FNs_middle_TMSRTE" in BIT vorgesehen sind, können diese in Gleichung 2 eingesetzt werden, um AOB_ELEMENT#y und AOB_FRAME#x zu berechnen. Nachdem dies erfolgt ist, kann die Abspielvorrichtung auf TKTMSRT von AOB Bezug nehmen, die erste Adresse von AOB_ELEMENT#2 (das das (y + 2)-te AOB_ELEMENT in diesem AOB ist) berechnen und die Suche nach AOB_FRAME#x ab dieser ersten Adresse beginnen. Bei Auffinden des x-ten AOB_FRAME beginnt die Abspielvorrichtung das Abspielen ab diesem Frame. Auf diese Weise kann die Abspielvorrichtung das Abspielen von Daten ab der von Jmp_Entry (in Sekunden) angegebenen Zeit beginnen.
Dergestalt ist die Abspielvorrichtung nicht gezwungen, nach den ADTS-Header-Teilen von AOB_FRAMEs zu suchen, sondern muss die Suche nur in AOB_ELEMENTs ausführen, die in TMSRT_entries in TKTMSRT gegeben sind. Dies bedeutet, dass die Abspielvorrichtung eine Abspielposition entsprechend einer eingegebenen Abspielzeit mit hoher Geschwindigkeit auffinden kann.
Auf dieselbe Weise muss, wenn Jmp_Entry eingestellt ist und die Zeitsuchfunktion in einer Spur, die sich aus einer Vielzahl von AOBs zusammensetzt, verwendet wird, die Abspielvorrichtung nur AOB_ELEMENT#y und AOB_FRAME#x berechnen, die der nachstehenden Gleichung 3 genügen.
Gleichung 3

Jmp_Entry (in Sekunden) = (FNs-1st_TMSRTE + FNs_middle_TMSRTE (#n+1) × y + x) × 20 msec

Die Gesamtabspieldauer der AOBs von AOB#1 bis AOB#n lautet folgendermaßen.
Gesamtabspieldauer der AOBs von AOB#1 bis AOB#n = [Anzahl von TMSRT_entries(#1) – 2) + „FNs_Last_TMSRTE" (#1) + „FNs_1st_TMSRTE" (#2) + („FNs_Middle_TMSRTE" (#2) × Anzahl von TMSRT_entries (#2) – 2) + „FNs_Last_TMSRTE" (#2) + „FNs_1st_TMSRTE" (#3) + („FNs_Middle_TMSRTE" (#3) × Anzahl von TMSRT_entries (#3) – 2) + „FNs_Last_TMSRTE" (#3) ... + „FNs_1st_TMSRTE" (#n) + („FNs_Middle_TMSRTE" (#n) × Anzahl von TMSRT_entries (#n – 2) + „FNs_Last_TMSRTE" (#n)] × 20 msec
Nach erfolgter Berechnung von AOB#n, AOB_ELEMENT#y und AOB_FRAME#x, die Gleichung 3 erfüllen, bezieht sich die Abspielvorrichtung auf TKTMSRT entsprechend AOB#n+1, sucht nach dem x-ten AOB_FRAME ab der Adresse, an der das (y + 2)-te AOB_ELEMENT (das heißt AOB_ELEMENT#y+2) positioniert ist, und beginnt mit dem Abspielen ab diesem x-ten AOB_FRAME.
{17-5_22-16_27A,B) Löschen einer AOB-Datei und einer TKI
Dies beendet die Erläuterung im Zusammenhang mit sämtlichen Informationen, die in TKI enthalten sind. Nachfolgend wird beschrieben, wie TKI in den nachfolgenden vier Fällen aktualisiert wird. Im ersten Fall (Fall 1) wird eine Spur gelöscht. Im zweiten Fall (Fall 2) wird eine Spur gelöscht und eine neue Spur aufgezeichnet. Im dritten Fall (Fall 3) werden zwei Spuren aus einer Vielzahl von Spuren ausgewählt und zu einer einzigen Spur kombiniert. Schließlich wird im vierten Fall (Fall 4) eine Spur in zwei Spuren unterteilt.
Nachfolgend wird Fall 1 beschrieben, in dem eine Spur gelöscht wird.
27A und 27B zeigen die teilweise erfolgende Löschung einer Spur. Das Beispiel in 27A und 27B entspricht dem in 19 gezeigten Spurverwalter (TrackManager) und geht davon aus, dass der Anwender die teilweise erfolgende Löschung von TrackB angegeben hat. AOB entsprechend TrackB wird in „A08002.SA1" mit einer Verknüpfung zu TKI#2 aufgezeichnet. Dies bedeutet, dass das Löschen von „AOB002.SA1" durch Einstellen von „nicht verwendet" (unused) in TKI_BLK_ATR von TKI#2 erfolgt. Der Zustand, in dem „AOB002.SA1" gelöscht ist und „unused" in TKI_BLK_ATR von TKI#2 eingestellt ist, ist in 27B gezeigt. Da „AOB002.SA1" gelöscht worden ist, ist der Bereich, der vorher von „AOB002.SA1" belegt war, frei und kann zu einem nicht verwendeten Bereich werden. Wie vorstehend erläutert worden ist, besteht die andere Änderung darin, dass „nicht verwendet" in TKI_BLK_ATR von TKI#2 eingestellt wird.
{17-5_22-17_28A,B} Zuweisung von TKIs, wenn ein neues AOB aufgezeichnet wird
Nachfolgend wird Fall 2 beschrieben, bei dem eine neue Spur aufgezeichnet wird, nachdem das Löschen einer Spur erfolgt ist.
28 zeigt den Spurverwalter, nachdem das Löschen von Spuren mehrmals vorgenommen worden ist. Wie in 28A gezeigt ist, wird dann, wenn Spuren entsprechend TKI#2, TKI#4, TKI#7 und TKI#8 gelöscht worden sind, „nicht verwendet" in TKI_BLK_ATR dieser TKI eingestellt. Während AOB-Dateien auf dieselbe Weise wie herkömmliche Datendateien gelöscht werden, wird der Spurverwalter durch einfaches Einstellen von „nicht verwendet" in TKI_BLK_ATR der entsprechenden TKI aktualisiert. Dies bedeutet, dass TKIs, deren TKI_BLK_ATRs auf „nicht verwendet" eingestellt werden, an verschiedenen Orten in dem Spurverwalter erscheinen können.
28B zeigt, wie eine neue TKI und AOB-Datei geschrieben werden, wenn TKI mit einer Belegung von TKI_BLK_ATR auf „nicht verwendet" in dem Spurverwalter vorhanden ist. Wie in 28A sind TKI#2, TKI#4, TKI#5, TKI#7 in 28B auf „nicht verwendet" (unused) eingestellt.
In 28B setzt sich die neu zu schreibende Spur aus vier AOBs zusammen. Die nicht verwendeten TKIs, die zum Aufzeichnen dieser AOBs verwendet werden, werden entsprechend DPL_TK_SRPs bestimmt und können frei gewählt werden. Beim vorliegenden Beispiel werden die nicht verwendeten TKIs mit den Nummern TKI#2, TKI#4, TKI#7, TKI#8 für die neue Spur verwendet.
Da diese vier AOBs eine Spur bilden, wird „Head_of_Track" in TKI_BLK_ATR von TKI#2, „Middle_of_Track" in TKI_BLK_ATR von TKI#4 und TKI#7 und „End_of_Track" in TKI_BLK_ATR von TKI#8 eingestellt. TKI_LNK_PTR in jeder der vier TKIs TKI#2, TKI#4, TKI#7 und TKI#8 zur Verwendung bei der Bildung der neuen Spur TrackD wird derart eingestellt, dass die TKI, die den nächsten Teil von TrackD bildet, gezeigt ist, sodass, wie durch die Pfeile TL2, TL4, TL7 gezeigt ist, TKI#4 in TKI_LNK_PTR von TKI#2, TKI#7 in TKI_LNK_PTR von TKI#4 und TKI#8 in TKI_LNK_PTR von TKI#7 eingestellt werden.
Anschließend werden die Dateien „AOB002.SA1", „AOB004.SA1", „AOB007.SA1" und „AOB008.SA1" mit denselben Nummern wie TKI#2, TKI#4, TKI#7 und TKI#8 erzeugt, und die vier AOBs, die TrackB bilden, werden in diesen vier Dateien gespeichert.
Durch geeignetes Einstellen von TKI_LNK_PTRs und TKI_BLK_ATRs kann diese vierte Spur TrackD unter Verwendung von TKI#2, TKI#4, TKI#7, TKI#8 verwaltet werden.
Wie vorstehend beschrieben worden ist, werden, wenn eine neue Spur in den Flashkartenspeicher 31 geschrieben wird, TKIs in dem Spurverwalter, die als „nicht verwendet" eingestellt sind, als TKIs zugewiesen, die für Spuren verwendet werden, die neu aufgezeichnet werden sollen.
{17-5_22-18_29A,B} Einstellen von TKI beim Kombinieren von zwei Spuren
Nachfolgend wird das Aktualisieren von TKI beschrieben, wenn Spuren kombiniert werden (Fall 3).
29A und 29B zeigen, wie TKIs eingestellt werden, wenn zwei Spuren zu einer neuen Spur kombiniert werden sollen. Das Beispiel in 29 bedient sich desselben Spurverwalters wie 19 und zeigt denjenigen Fall, in dem der Anwender eine Bearbeitungsoperation zum Kombinieren von TrackC und TrackE zu einer einzigen Spur vornimmt.
In diesem Fall werden AOBs, die TrackC und TrackE entsprechen, in den AOB-Dateien „AOB003.SA1" und „AOB008.SA1" aufgezeichnet, die TKI#3 und TKI#8 entsprechen, weshalb die TKI_BLK_ATRs von TKI#3 und TKI#8 neugeschrieben werden. 29B zeigt TKI_BLK_ATR dieser TKIs nach dem Neuschreiben. Gemäß 29A werden TKI_BLK_ATRs von TKI#3 und TKI#8 als „Spur" (Track) geschrieben, wohingegen gemäß 29B TKI_BLK_ATR von TKI#3 auf „Head_of_Track" und TKI_BLK_ATR von TKI#8 als „End_of_Track" neugeschrieben wird. Durch auf diese Weise erfolgendes Neuschreiben der TKI_BLK_ATRs werden die AOB-Dateien „AOB003.SA1" und „AOB008.SA1", die TKI#3 und TKI#8 entsprechen, letztendlich als Teile einer einzigen Spur behandelt, nämlich von TrackC. Einhergehend mit diesem Vorgang wird TKI_LNK_PTR von TKI#3 neugeschrieben, um TKI#8 anzugeben.
Es sollte insbesondere beachtet werden, dass während TKI_BLK_ATRs in TKI neugeschrieben werden, keine Verarbeitung dahingehend vorgenommen wird, dass die AOB-Dateien „AOB003.SA1" und „AOB008.SA1" physisch kombiniert werden. Dies rührt daher, dass AOB-Dateien jeweils unter Verwendung verschiedener FileKeys verschlüsselt sind, sodass es beim Kombinieren von AOB-Dateien notwendig würde, zwei Vorgänge für jede AOB-Datei auszuführen, bei denen zunächst die verschlüsselte AOB-Datei entschlüsselt und anschließend das Ergebnis neuverschlüsselt wird, was zu einer übermäßig großen Verarbeitungsbelastung führen würde. Darüber hinaus wurde eine AOB-Datei, die auf diese Weise kombiniert wird, unter Verwendung eines einzelnen FileKey verschlüsselt werden, was die kombinierte Spur weniger sicher als diejenigen Spuren machen würde, die zu deren Erzeugung verwendet worden sind.
Die TKI ist ursprünglich derart ausgelegt, dass sie die Größe von TKTMSRT verringert, sodass das physische Kombinieren von AOB-Dateien durch eine Bearbeitungsoperation auch das Risiko in sich tragen würde, das TKI zu groß wird.
Aus vorstehend genannten Gründen belassen Bearbeitungsoperationen, die Spuren kombinieren, die AOB-Dateien in ihrem verschlüsselten Zustand, wobei die Änderung durch bloßes Ändern der durch die TKI_BLK_ATRs gegebenen Attribute ereicht wird.
{17-5_22-18_29A,B-1_30,31} Bedingungen, die beim Kombinieren von Spuren erfüllt sein müssen
Das Kombinieren von Spuren wird durch Ändern von TKI_BLK_ATR-Attributen gemäß vorstehender Beschreibung ausgeführt, wobei die AOBs, die in kombinierten Spuren enthalten sind, die nachfolgenden Bedingungen erfüllen sollten.
Eine erste Bedingung besteht darin, dass dasjenige AOB, das einen letzteren Teil einer neuen Spur bilden soll, dieselben Audioattribute (Audiocodiermodus, Bitrate, Abtastfrequenz, Anzahl von Kanälen und dergleichen) wie dasjenige AOB aufweisen sollte, das den ersten Teil der neuen Spur bilden wird. Weist ein AOB verschiedene Audioattribute im Vergleich zu dem vorhergehenden oder nachfolgenden AOB auf, so muss die Ab spielvorrichtung den Betrieb des Decoders zurücksetzen, was ein nahtloses Abspielen (das heißt ein Abspielen ohne Unterbrechung) von aufeinanderfolgenden AOBs schwierig macht.
Die zweite Bedingung besteht darin, dass in der durch das Kombinieren erzeugten Spur drei oder mehr AOBs, die nur aus AOB_ELEMENTs bestehen, deren Anzahl unterhalb der erforderlichen Anzahl für „FNs_Middle_TMSRTE" ist, nicht verknüpft werden können.
AOBs werden in zwei Typen eingeteilt, was davon abhängt, ob wenigstens ein AOB_ELEMENT dieselbe Anzahl von AOB_FRAMEs wie die Anzahl von Frames gemäß Vorgabe für „FNs_Middle_TMSRTE" enthält. Das AOB vom Typ 1 enthält wenigstens ein AOB_ELEMENT mit dieser Anzahl von AOB_FRAMEs, wohingegen ein AOB vom Typ 2 kein AOB_Element mit dieser Anzahl von AOB_FRAMEs enthält.
Mit anderen Worten, AOB_ELEMENTs in einem AOB vom Typ 2 weisen weniger AOB_FRAMEs als „FNs_Middle_TMSRTE" auf, wobei die zweite Bedingung angibt, dass drei AOBs vom Typ 3 nicht miteinander verknüpft werden können.
Der Grund für die zweite Bedingung lautet folgendermaßen. Liest die Abspielvorrichtung AOBs aufeinanderfolgend, so wird für eine bestimmte Anzahl von AOB_FRAMEs vorgezogen, wenn diese in dem Puffer der Abspielvorrichtung gesammelt werden, was jedoch nicht erfolgen kann, wenn aufeinanderfolgende AOBs vom Typ 2 vorhanden sind. In diesem Fall tritt wahrscheinlich ein Unterlauf (underflow) in dem Speicher der Abspielvorrichtung auf, sodass ein Abspielen ohne Unterbrechung seitens der Abspielvorrichtung nicht mehr gewährleistet werden kann. Um daher einen derartigen Unterlauf zu vermeiden, wird die zweite Bedingung verwendet, die angibt, dass drei oder mehr AOBs vom Typ 2 nicht kontinuierlich verknüpft werden können.
30A zeigt ein AOB vom Typ 1, während 30B zwei Beispiele für AOBs vom Typ 2 zeigt. Gemäß 30B sind beide AOBs aus weniger als zwei AOB_ELEMENTs zusammengesetzt, wobei kein AOB_ELEMENT eine Anzahl von AOB_FRAMEs aufweist, die für „FNs_Middle_TMSRTE" eingestellt ist. Aufgrund des Nichtvorhandenseins von AOB_ELEMENT mit der Anzahl von AOB_FRAMEs gemäß Einstellung für „FNs_Middle_TMSRTE" ergibt sich mit Blick auf die Bedingung, wonach ein AOB als AOB vom Typ 2 klassifiziert wird, dass alle in dieser Figur gezeigten AOBs als AOBs vom Typ 2 zu klassifizieren sind.
In 31A ist eine Kombination von AOBs vom Typ 1 und Typ 2 und Typ 2 und Typ 1 zu einer einzigen Spur gezeigt. Da dieses Kombinieren nicht das Verknüpfen von AOBs vom Typ 2 impliziert, können diese AOBs zu einer einzigen Spur verknüpft werden.
31B zeigt die Verknüpfung von AOBs vom Typ 1 und Typ 2 und Typ 2 und Typ 2 und Typ 1 zu einer einzelnen Spur. Dieses Kombinieren würde dazu führen, dass drei aufeinanderfolgende AOBs vom Typ 2 vorhanden sind, und ist daher verboten.
{17-5_22-18_29A,B-1_32} Kombinieren von Spuren bei Kombinationen von AOBs vom Typ 1 und Typ 2
Beim Kombinieren von AOBs zu einer einzigen Spur kann, wie in 31 gezeigt ist, für den Fall, dass das letzte AOB in der ersten Spur ein AOB vom Typ 1 ist, das Kombinieren unabhängig davon vorgenommen werden, ob der erste Teil dieser Spur ein AOB vom Typ 1 oder ein AOB vom Typ 2 ist. 32A zeigt denjenigen Fall, in dem das letzte AOB in der ersten Spur ein AOB vom Typ 1 und das erste AOB in der nächsten Spur ebenfalls ein AOB vom Typ 1 ist. 32B zeigt denjenigen Fall, in dem das letzte AOB in der ersten Spur ein AOB vom Typ 1 und das erste AOB in der nächsten Spur ein AOB vom Typ 2 ist. Da die zweite Bedingung in beiden Fällen erfüllt ist, können die dargestellten Spuren zu einer einzigen Spur kombiniert werden.
Ist das letzte AOB in der ersten Spur ein AOB vom Typ 2 und das vorhergehende AOB in der ersten Spur ein AOB vom Typ 1, so kann die erste Spur mit einer nachfolgenden Spur kombiniert werden, die mit einem AOB vom Typ 1 beginnt, und zwar unabhängig davon, ob das erste AOB in der ersten Spur ein AOB vom Typ 1 oder ein AOB vom Typ 2 ist.
32C zeigt denjenigen Fall, in dem die erste Spur mit einem AOB vom Typ 1 und einem AOB vom Typ 2 in dieser Reihenfolge endet und die zweite Spur mit einem AOB vom Typ 1 beginnt. 32D zeigt denjenigen Fall, in dem die erste Spur mit einem AOB vom Typ 1 und einem AOB vom Typ 2 in dieser Reihenfolge endet und die zweite Spur mit einem AOB vom Typ 2 und einem AOB vom Typ 1 in dieser Reihenfolge beginnt. Da die zweite Bedingung in beiden Fällen erfüllt ist, können die dargestellten Spuren zu einer einzigen Spur kombiniert werden.
Endet die erste Spur mit einem AOB vom Typ 2 und ist das unmittelbar vorausgehende AOB ebenfalls ein AOB vom Typ 2, so kann die erste Spur mit einer nachfolgenden Spur kombiniert werden, die mit einem AOB vom Typ 1 beginnt. 32E zeigt denjenigen Fall, in dem die erste Spur mit AOBs vom Typ 2 endet und die zweite Spur mit einem AOB vom Typ 2 beginnt. Da die zweite Bedingung in diesem Fall erfüllt ist, können die dargestellten Spuren zu einer einzigen Spur kombiniert werden. Auf diese Weise wird, wenn zwei Spuren kombiniert werden sollen, eine Untersuchung darüber durchgeführt, ob die beiden Spuren die erste und zweite Bedingung erfüllen, wobei die beiden Spuren nur dann kombiniert werden, wenn sich ergibt, dass sie die Bedingungen erfüllen.
Nachfolgend wird das Aktualisieren von TKI für Fall 4 beschrieben, in dem eine Spur unterteilt wird.
{17-5_22-19_33A,B} Einstellungen für TKI bei Unterteilung einer Spur
33A und 33B zeigen Beispiele für den Fall, in dem eine einzelne Spur in zwei neue Spuren unterteilt werden soll. Für diese Beispiele ist der Inhalt des Spurverwalters derselbe wie in 27, wobei davon auszugehen ist, dass der Anwender eine Bearbeitungsoperation vorgenommen hat, die TrackC in zwei neue Spuren unterteilt, nämlich TrackC und TrackF. Soll TrackC in zwei neue Spuren TrackC und TrackF unterteilt werden, so wird die AOB-Datei „AOB002.SA1" entsprechend TrackF erzeugt. 33A zeigt, dass TKI#2 auf „nicht verwendet" eingestellt ist, wobei TKI#2 der neu erzeugten AOB-Datei „AOB002.SA1" zugewiesen wird.
{17-5_22-19-33A,B-1_34A,B} Aktualisieren der Verzeichniseinträge und FAT-Werte
Wird die AOB-Datei „AOB003.SA1" unterteilt, damit „AOB002.SA1" erzeugt wird, so müssen die Verzeichniseinträge und FAT-Werte aktualisiert werden. Dieses Aktualisieren wird nachstehend beschrieben. 34A zeigt, wie der SD-Audioverzeichniseintrag in dem SD-Audioverzeichnis, zu dem die AOB-Datei „AOB003.SA1" gehört, geschrieben wird, bevor die Datei unterteilt wird.
Die AOB-Datei „AOB003.SA1" wird in eine Vielzahl von Teilen unterteilt, die in Clustern 007, 008, 009, 00A ... 00B, 00E gespeichert werden. In diesem Fall wird die erste Clusternummer für die AOB-Datei „AOB003.SA1" gemäß Angabe in dem Verzeichniseintrag als „007" geschrieben. Die Werte (008), (009), (00A) ... (00D), (00E) werden ebenfalls in die FAT-Werte 007, 008, 009, 00A ... 00D entsprechend den Clustern 007, 008, 009, 00A ... 00D geschrieben.
Wird die AOB-Datei „AOB003.SA1" derart unterteilt, dass ihr letzter Teil zu der neuen AOB-Datei „AOB002.SA1" wird, so werden ein „Dateiname" (filename), eine „Dateinamenerweiterung" (filename extension) und eine „Nummer der ersten Cluster in der Datei" für die neue AOB-Datei „AOB002.SA1" dem SD-Audioverzeichniseintrag hinzugefügt. 34B zeigt, wie der SD-Verzeichniseintrag in dem SD-Audioverzeichnis, zu dem die AOB-Datei „AOB003.SA1" gehört, geschrieben wird, nachdem die AOB-Datei „AOB003.SA1" geteilt worden ist.
Wie in 34B gezeigt ist, speichert das Cluster 00F eine Kopie des Clusters 00B, das die Grenze enthält, die vom Anwender angegeben wird, wenn die Datei unterteilt wird. Die Teile der AOB-Datei „AOB002.SA1" im Gefolge des in dem Cluster 00B enthaltenen Teils werden wie zuvor in den Clustern 00C, 00D, 00E gespeichert. Da der erste Teil der AOB-Datei „AOB002.SA1" in dem Cluster 00F und die verbleibenden Teile in den Clustern 00C, 00D, 00E gespeichert sind, wird „00F" in die „Nummer des ersten Clusters in der Datei" für die neue AOB-Datei „AOB002.SA1" geschrieben, während (00C), (00D), (00E) in die FAT-Werte 00F, 00C, 00D, 00E entsprechend den Clustern 00F, 00C, 00D und 00E geschrieben werden.
{17-5_22-19_33A,B-2_35A,B} Einstellen der Informationsfelder in TKI
Nachfolgend wird beschrieben, wie die Informationsfelder in TKI für die AOB-Datei „AOB002.SA1" eingestellt werden, sobald man diese Datei durch Aktualisieren der Verzeichniseinträge und FAT-Werte ermittelt hat. Beim Erzeugen von TKI für eine unterteilte Spur gibt es zwei Arten von Informationsfeldern in TKI. Es handelt sich hierbei um (1) Informationen, die aus der ursprünglichen TKI kopiert werden können, und (2) Informationen, die sich durch Aktualisieren der Informationen in der ursprünglichen TKI ergeben. TKTXTI_DA und ISRC gehören zu ersterer Art, während BIT, TKTMSRT und die anderen Informationsfelder zu letzterer Art gehören. Da beide Arten von Informationen vorhanden sind, erzeugt das vorliegende Ausführungsbeispiel eine TKI für eine unterteilte Spur durch Kopieren der ursprünglichen TKI zur Erzeugung einer Mustervorlage für die neue TKI und anschließendes Unterteilen/Aktualisieren von TKTMSRT und BIT in dieser Mustervorlage und Aktualisieren der verbleibenden Informationsfelder.
35A zeigt denjenigen Fall, in dem AOB_FRAME unterteilt wird. Die erste Ebene in 35A zeigt die vier Elemente AOB_ELEMENT#1, AOB_ELEMENT#2, AOB_ELEMENT#3 und AOB_ELEMENT#4. Die Datenlängen von AOB_ELEMENTs werden in TKTMSRT als die vier TMSRT_entries #1, #2, #3, #4 eingestellt. Wird die Grenze bd1 für die Unterteilung in AOB_ELEMENT#2, siehe 35A, eingestellt, so wird AOB_ELEMENT#2 in einen ersten Bereich (1), der aus denjenigen Frames besteht, die sich vor der Grenze bd1 befinden, und einen zweiten Bereich (2), der sich aus denjenigen Frames zusammensetzt, die sich nach der Grenze bd1 befinden, unterteilt. 35B zeigt die beiden AOBs AOB#1 und AOB#2, die man durch Unterteilen von AOB mitten durch AOB_ELEMENT#2 erhält.
{17-5_22-19_33A,B-3_36} Einstellen von BIT
36 zeigt, wie BIT eingestellt wird, wenn AOB, wie in 35 gezeigt ist, unterteilt wird. Das in 35 gezeigte AOB wird an der Grenze bd1 unterteilt. Das durch diese Unterteilung erzeugte AOB#1 enthält die beiden AOB_ELEMENTE AOB_ELEMENT#1 und AOB_ELEMENT#2, während das andere AOB#2, das durch diese Unterteilung erzeugt wird, die drei AOB_ELEMENTs AOB_ELEMENT#1, AOB_ELEMENT#2 und AOB_ELEMENT#3 enthält.
Wie in 36 gezeigt ist, werden an diese AOB_ELEMENTs ebenfalls dreieckige Merker (flags) vergeben, um die Einstellungen der TMSRT_Einträge anzuzeigen, die in den TKIs entsprechend diesen AOBs enthalten sind. Die Erläuterung stellt zunächst auf AOB#1 ab, das man durch diese Unterteilung erhält. AOB_ELEMENT#1 und AOB_ELEMENT#2, die in AOB#1 enthalten sind, belegen Cluster 007 bis Cluster 00A, sodass AOB#1 als Zusammensetzung von Cluster 007 bis Cluster 00A behandelt wird. AOB_ELEMENT#2 in AOB#1 weist eine Datenlänge auf, die nicht am Ende des Clusters 00A, sondern an der Grenze bd1 endet, die innerhalb des Clusters 008 befindlich ist, sodass SZ_DATA für AOB#1 als Datenmenge von dem Bereich md0 zur Grenze bd1 in dem Cluster 00A gegeben ist. "FNs_1st_TMSRTE" für AOB#1 entspricht dem Zustand vor der Unterteilung, während sich "FNs_Last_TMSRTE" für AOB#1 von dem Wert, der vor der Unterteilung vorhanden war, dadurch unterscheidet, dass nunmehr die Anzahl der Frames vom Anfang von AOB_ELEMENT#2 vor der Unterteilung bis zur Grenze bd1 angegeben wird.
Nachfolgend wird AOB#2 beschrieben, das man durch diese Unterteilung erhält. AOB_ELEMENT#1, AOB_ELEMENT#2 und AOB_ELEMENT#3, die in AOB#2 enthalten sind, belegen Cluster 00B bis Cluster 007. Das Cluster 00F enthält eine Kopie des Inhaltes des Clusters 00A. Der Grund dafür, dass das Cluster 00F eine Kopie des Clusters 00A speichert, besteht darin, dass das Cluster 00A von AOB_ELEMENT#2 in AOB#1 belegt ist, weshalb es notwendig wird, AOB_ELEMENT#1 in AOB#2 ein anderes Cluster zuzuweisen.
AOB_ELEMENT#1 in AOB#2 weist eine Datenlänge auf, die nicht am Beginn des Clusters 00F, sondern an der Grenze bd1, die innerhalb des Clusters 00F befindlich ist, anfängt, sodass SZ_DATA für AOB#2 als Datenmenge vom Anfang des Clusters 00B zu einem Punkt mitten durch das Cluster 00E plus die Datenlänge des Teils des Clusters 00F, das von AOB_ELEMENT#1 belegt ist, gegeben ist.
Derjenige Teil von AOB_ELEMENT#2 in AOB#1, der in der Kopie von Cluster 00A gemäß Speicherung in dem Cluster 00F enthalten ist, muss aus AOB#2 ausgeschlossen werden, sodass das DATA_Offset-Feld in BIT von AOB#2 auf die Größe des Teiles von AOB_ELEMENT#2 in AOB#1, das in dem Cluster 00F enthalten ist, eingestellt wird.
Wie aus 36 ersichtlich ist, führt die Unterteilung von AOB dazu, dass AOB_ELEMENT, das die Grenze für die Unterteilung enthält, in zwei Bestandteile unterteilt wird und die anderen AOB_ELEMENTs, die vor oder nach dem unterteilten AOB_ELEMENT befindlich sind, unverändert bleiben. Im Ergebnis werden „FN_Last_TMSRTE" von AOB#2 auf denselben Wert für „AOB_ELEMENT#4" vor der Unterteilung und „FN_1st_TMSRTE" von AOB#2 auf AOB_ELEMENT#1 von AOB#2 eingestellt, das heißt die Anzahl von Frames, die in demjenigen Teil enthalten sind, der auf die Grenze folgt, sobald AOB_ELEMENT#2 unterteilt worden ist.
{17-5_22-19_33A,B-4_37} Einstellen von BIT
37 zeigt ein spezielles Beispiel für Änderungen in BITs als Ergebnis der Unterteilung einer Spur. Die linke Seite von 37 zeigt ein Beispiel für Einstellungen von BIT vor der Unterteilung. In BIT sind Data_Offset auf „X" und SZ_DATA auf „52428" eingestellt, während TMSRTE_Ns auf „n" eingestellt ist. FNs_1st_TMSRTE ist auf „80 Frames", FNs_Middle_TMSRTE auf „94 Frames" und FNs_Last_TMSRTE auf „50 Frames" eingestellt.
Die rechte Seite von 37 zeigt die Einstellungen von zwei BITs, die durch Unterteilen einer Spur erzeugt worden sind. Wird AOB entsprechend BIT auf der linken Seite von 37 unterteilt, wie in 35A gezeigt ist, so wird Data Offset in BIT der ersten Spur aus der Erzeugung durch die Unterteilung genau wie die Spur vor der Unterteilung auf „X" eingestellt, „SZ_DATA" wird auf die Datenlänge „Q" vom Anfang zum Unterteilungspunkt Q aktualisiert, und TMSRTE_Ns wird auf „K" eingestellt, das die Anzahl der TMSRT_Einträge vom ersten TMSRT_Eintrag zum k-ten TMSRT_Eintrag zeigt. FNs_1st_TMSRTE und FNs_Middle_TMSRTE werden auf dieselbe Weise wie BIT vor der Unterteilung auf „80" beziehungsweise „94" Frames eingestellt, wobei jedoch aufgrund der Tatsache, dass das letzte AOB_ELEMENT in AOB der ersten Spur aus der Erzeugung durch die Unterteilung „p" AOB_FRAMEs enthält, FNs_Last_TMSRTE auf „p" Frames eingestellt wird.
In BIT der zweiten Spur aus der Erzeugung durch die Unterteilung werden „Data Offset" auf „R" und „SZ_DATA" auf (ursprüngliches SZ#DATA „52428" – Datenlänge bis zum Unterteilungspunkt Q) eingestellt, während TMSRTE_Ns auf „n – k + 1" eingestellt wird, das sich aus der Addition von 1 (für den k-ten TMSRT_Eintrag, der als Ergebnis der Unterteilung neu hinzugefügt wird) zur Anzahl der TMSRT_Einträge vom k-ten TMSRT_Eintrag bis zum n-ten TMSRT_Eintrag ergibt.
FNs_Middle_TMSRTE und FNs_Last_TMSRTE werden auf dieselben Werte wie BIT vor der Unterteilung eingestellt, das heißt „94 Frames" beziehungsweise „50 Frames".
Das erste AOB_ELEMENT in AOB der zweiten Spur enthält „94 – p" AOB_FRAMEs, sodass „94 – p" in FNs_1_st_TMSRTE von BIT entsprechend dieser Spur eingestellt wird.
{17-5_22-19_33A,B-5_38} Einstellen von BIT
38 zeigt TKTMSRT nach der Unterteilung. Nachfolgend werden zunächst die Einstellungen von TMSRT erläutert. TMSRT der ersten Spur enthält TMSRT_Einträge vom ersten TMSRT_Eintrag von AOB vor der Unterteilung zum k-ten TMSRT_Eintrag, das heißt die TMSRT_Einträge #1 bis #k.
Man beachte hierbei, dass AOB_ELEMENT #k, das die Grenze für die Unterteilung enthält, nur den Bereich (1) enthält, sodass der k-te TMSRT_Eintrag nur eine Datengröße entsprechend diesem Bereich (1) enthält. TMSRT der zweiten Spur enthält die TMSRT_Einträge für den k-ten TMSRT_Eintrag von AOB vor der Unterteilung bis zum n-ten TMSRT_Eintrag, das heißt die TMSRT_Einträge #k bis #n. Man beachte hierbei zudem, dass AOB_ELEMENT#k, das die Grenze für die Unterteilung enthält, nur den Bereich (2) enthält, sodass der k-te TMSRT_Eintrag nur eine Datengröße entsprechend diesem Bereich (2) enthält.
Das Kopieren von TKI geht mit einem Unterteilen und Aktualisieren von TKTMSRT und BIT einher, und sobald die verbliebenen Informationen aktualisiert worden sind, sind die TKIs für die neuen Spuren, die durch die Unterteilung erzeugt worden sind, vollständig. Auf dieselbe Weise werden beim Kombinieren von Spuren die AOB-Dateien nicht entschlüsselt, sodass zwei Spuren durch Unterteilen einer AOB-Datei in deren verschlüsseltem Zustand erzeugt werden können. Da die Unterteilung einer AOB-Datei nicht mit einer Entschlüsselung und einer Neuverschlüsselung einhergeht, kann die Verarbeitungslast beim Unterteilen einer Spur verringert werden. Dies bedeutet, dass Spuren auch bei einer Abspielvorrichtung mit begrenzter Verarbeitungsleistung bearbeitet werden können.
Dies beendet die Erläuterung von TKI. Nachstehend werden die Spiellisten (playlists) beschrieben.
{17-6} Spiellistenverwalter (PlaylistManager)
Wie durch die gestrichelten Linien h5 in 17 gezeigt ist, umfasst der gezeigte Spiellistenverwalter PlaylistManager Information (PLMGI) (Spiellistenverwalterinformation) zum Verwalten der auf der Flashspeicherkarte 31 gespeicherten Spiellisten, Default_Playlist_Information (DPLI) (Standardspiellisteninformation) zum Verwalten von allen auf der Flashspeicherkarte 31 gespeicherten Spuren und PlaylistInformation (PLI) (Spiellisteninformation) #1, #2, #3, #4 ... #m. Jede PLI ist eine Information für eine anwenderdefinierte Spielliste. Wie durch die gestrichelten Linien h6 gezeigt ist, umfasst DPLI Default_Playlist_General_Information (DPLGI) (Allgemeine Standardspiellisteninformation), und Default_Playlist_Track_Search_Pointers (DPL_TK_SRP) (Standardspiellistenspursuchzeiger) #1, #2, #3, #4 ... #m. Wie durch die gestrichelten Linien h7 gezeigt ist, umfasst jede PLI_Playlist_General Information (PLGI) (allgemeine Spiellisteninformation) und Playlist_Track_Search_Pointers (PL_TK_SRP) (Spiellistenspursuchzeiger) #1, #2, #3, #4 ... #m.
Die hier beschriebene DPLI unterscheidet sich von anderen PLIs auf nachfolgende Weise. Während DPLI sämtliche auf der Flashspeicherkarte 52 gespeicherten Spuren anzeigen muss, tritt bei PLI diese Beschränkung nicht auf, und es kann eine beliebige Anzahl von Spuren angezeigt werden. Dies eröffnet dem Anwender verschiedene Möglichkeiten. Als repräsentatives Beispiel sei genannt, dass der Anwender Spiellisteninformationen erzeugen kann, die seinen/ihre Lieblingsspuren angibt, und diese Spiellisteninformation (Playlist_Information) auf der Flashspeicherkarte 31 speichern kann. Alternativ kann der Anwender die Abspielvorrichtung veranlassen, automatisch eine Spiellisteninformation zu erzeugen, die nur Spuren eines bestimmten Genres aus der Vielzahl von auf der Flashspeicherkarte 31 gespeicherten Spuren anzeigt, und die sich ergebende Spiellisteninformation auf der Flashspeicherkarte 31 zu speichern.
{17-7_18} Anzahl von Spiellisten und ihre Datengrößen
Wie in 18 gezeigt ist, kann eine Maximalzahl von 99 Spiellisten auf der Flashspeicherkarte 31 gespeichert werden. Die kombinierte Datengröße von PlaylistManager Information (PLMGI) und Default_Playlist_Information (DPLI) ist ebenfalls fest auf 2.560 Byte eingestellt. Jede PLI weist eine feste Länge von 512 Byte auf. „DPL_TK_SRP", der in Default_Playlist_Information enthalten ist, enthält „DPL_TK_ATR" und „DPL_TKIN". Demgegenüber enthält der in PLI enthaltene „PL_TK_SRP" nur „PL_TK_SRP". Das Format der DPL_TK_ATR-, DPL_TKIN- und PL_TKIN-Felder ist in 39 gezeigt.
{17-8_39-1} Format von DPL_TK_SRP
39A zeigt das Format von DPL_TK_SRP. In 39A ist DPL_TKIN in das 0. bis 9. Bit in DPL_TK_SRP geschrieben, während DPL_TK_ATR in das 13. bis 15. Bit geschrieben ist. Das 10. bis 12. Bit in DPL_TK_SRP sind für zukünftige Verwendungen reserviert.
Die TKI-Nummer wird in DPL_TKIN geschrieben, die das 0. bis 9. Bit in DPL_TK_SRP belegt. Dies ermöglicht eine Spezifizierung von TKI.
{17-9_39B} Format von PL_TK_SRP
39B zeigt das Format von PL_TK_SRP. Es handelt sich hierbei um ein 10 Bit umfassendes Feld, in dem PL_TKIN, das heißt eine TKI-Nummer geschrieben wird.
{17-8_39A-2} Zusammensetzung von DPL_TK_ATR
Die gestrichelten Linien h51 und h52, die sich in 39A von DPL_TK_ATR aus erstrecken, zeigen ein Beispiel für die Einstellung von DPL_TK_ATR. Wie aus dieser Figur ersichtlich ist, ist DPL_TK_ATR für DPL_TK_SRP auf dieselbe Weise wie TKI_BLK_ATR für TKI eingestellt, das heißt, DPL_TK_ATR ist auf „Track", „Head_of_Track", „Midpoint_of_Track und „End_of_Track" eingestellt.
Im Detail bedeutet dies, dass bei Verwendung der von TKIN angezeigten TKI und Aufzeichnung eines Audioobjektes (AOB) entsprechend einer vollständigen Spur in der AOB-Datei entsprechend der angezeigten TKI (das heißt, wenn TKI_BLK_ATR von TKI gleich „Track" ist) der Wert „00b" in „DPL_TK_ATR" eingestellt wird.
Bei Verwendung der von TKIN angezeigten TKI und Aufzeichnung eines Audioobjektes (AOB) entsprechend nur dem Anfang einer Spur in der AOB-Datei entsprechend der angezeigten TKI (das heißt, wenn TKI_BLK_ATR von TKI gleich „Head_of_Track" ist) wird der Wert „001b" in „DPL_TK_ATR" eingestellt. Bei Verwendung der von TKIN angezeigten TKI und Aufzeichnung eines Audioobjektes (AOB) entsprechend dem Mittelteil einer Spur in der AOB-Datei entsprechend der angezeigten TKI (das heißt, wenn TKI_BLK_ATR von TKI gleich „Midpoint_of_Track" ist) wird der Wert „010b" in „DPL_TK_ATR" eingestellt. Bei Verwendung der von TKIN angezeigten TKI und Aufzeichnung eines Audioobjektes (AOB) entsprechend einem Endteil einer Spur in der AOB-Datei entsprechend der angezeigten TKI (das heißt, wenn TKI_BLK_ATR von TKI gleich „End_of_Track" ist) wird der Wert „011b" in „DPL_TK_ATR" eingestellt.
Wird im Umkehrfall die von TKIN angezeigte TKI nicht verwendet und ist der TKI-Bereich dennoch vorhanden, was demjenigen Fall entspricht, dass TKI gelöscht worden ist (das heißt, wenn TKI_BLK_ATR von TKI gleich „nicht verwendet" ist), so wird in DPL_TK_ATR der Wert „100b" eingestellt.
Wird die von TKIN angezeigte TKI nicht verwendet und ist kein TKI-Bereich vorhanden, was demjenigen Fall entspricht, dass TKI im Anfangszustand befindlich ist (das heißt, wenn TKI im Anfangszustand befindlich ist), so wird in DPL_TK_ATR der Wert "101b" eingestellt.
Da die Nummer von TKI in DPL_TKIN geschrieben ist, ist deutlich, was aus der Vielzahl von TKI jedem DPL_TK_SRP entspricht. Die Position von DPL_TK_SRP in Default_Playlist_Information zeigt, wenn das AOB entsprechend TKI, das wiederum DPL_TK_SRP entspricht, abgespielt wird, das heißt die ordinale Position von AOB in Default_Playlist (Standardabspielliste). Im Ergebnis bezeichnet die Reihenfolge von DPL_TK_SRP-Objekten (Items) in der Standardabspielliste die Reihenfolge, mit der eine Vielzahl von Spuren abgespielt wird. Mit anderen Worten, sie bestimmt die Abspielreihenfolge der Spuren.
{17-9_40-1} Wechselseitige Beziehung zwischen Default_Playlist_Information, TKI und AOB-Dateien
40 zeigt die wechselseitige Beziehung zwischen Default_Playlist_Information, TKI und den AOB-Dateien. Die zweite, dritte und vierte Ebene in dieser Figur sind dieselben wie die erste, zweite und dritte Ebene in 19 und zeigen daher einen Spurverwalter, der acht TKIs und acht AOBs enthält. 40 unterscheidet sich von 19 dahingehend, dass ein Kasten, der die Standardspiellisteninformation (Default_Playlist_Information) angibt, auf der ersten Ebene gezeigt ist. Die acht kleinen Unterteilungen, die in diesem Kasten gezeigt sind, zeigen die acht DPL_TK_SRP, die in der Standardspiellisteninformation enthalten sind. Der obere Teil jeder Unterteilung zeigt DPL_TK_ATR, während der untere Teil DPL_TKIN zeigt.
Wie durch die Pfeile DT1, DT2, DT3, DT4 ... in 40 gezeigt ist, sind DPL_TK_SRP#1 und TKI#1 genauso wie DPL_TK_SRP#2 und TKI#2, DPL_TK_SRP#3 und TKI#3 sowie DPL_TK_SRP#4 und TKI#4 verwandt.
Mit Blick auf die DPL_TK_ATR-Felder in DPL_TR_SRP ist ersichtlich, dass "Track" jeweils für DPL_TK_SRP#1, DPL_TK_SRP#2, DPL_TK_SRP#3 und DPL_TK_SRP#8 eingestellt ist. Mit anderen Worten, die vier Kombinationen DPL_TK_SRP#1 → TKI#1 (,AOB001.SA1"), DPL_TK_SRP#2 → TKI#2 („AOB002.SA1"), DPL_TK_SRP#3 → TKI#3 („AOB003.SA1") und DPL_TK_SRP#8 -• TKI#8 („AOB008.SA1") entsprechen vier getrennten Spuren.
Weder DPL_TK_SRP#4, noch DPL_TK_SRP#5, noch DPL_TK_SRP#6, noch DPL_TK_SRP#7 weist DPL_TK_ATR auf, das auf „Track" eingestellt ist. Anstelle dessen sind DPL_TK_SRP#4 von DPL_TK_ATR auf „Head_of_Track", DPL_TK_ATR von DPL_TK_SRP#7 auf „End_of_Track" und die DPL_TK_ATRs von DPL_TK_SRP#5 und DPL_TK_SRP#6 auf „Midpoint_of_Track" eingestellt.
Dies bedeutet, dass TKI#4 („AOB004.SA1"), die mit DPL_TK_SRP#4 verwandt ist, der Anfang einer Spur ist, TKI#5 („AOB005.SA1") und TKI#6 („AOB006.SA1"^), die mit DPL_TK_SRP#5 beziehungsweise DPL_TK_SRP#6 verwandt sind, Mittelteile einer Spur sind, und TKI#7 („AOB007.SA1"), die mit DPL_TK_SRP#7 verwandt ist, das Ende einer Spur ist.
Die DPL_TK_SRP-Einträge in der Standardspielliste zeigen, in welcher Reihenfolge die AOBs entsprechend jeder TKI abgespielt werden. Die DPL_TKINs von DPL_TK#1, #2, #3, #4, ..., #8 in der Standardspielliste von 40 zeigen TKI#1, #2, #3, #4, ..., #8 an. Wie durch die Pfeile (1), (2), (3), (4), ... (8) gezeigt ist, wird zunächst die AOB-Datei „AOB001.SA1" entsprechend TKI#1 abgespielt, anschließend wird „AOB002.SA1" entsprechend TKI#2 als zweites abgespielt, sodann wird „AOB003.SA1" entsprechend TKI#3 als drittes abgespielt und schließlich wird „AOB004.SA1" entsprechend TKI#4 als viertes abgespielt.
{17-10_41} Beispielseinstellungen für die Standardspielliste und Spiellisteninformation
41 zeigt Beispielseinstellungen für die Standardspielliste und die Spiellisteninformation unter Verwendung derselben Notation wie in 40. In 41 zeigt der Kasten auf der ersten Ebene die Standardspielliste (Default_Playlist), während die drei Kästen auf der zweiten Ebene PLIs zeigen.
Die kleinen Unterteilungen in dem Kasten, der die Standardspielliste zeigt, zeigen die acht DPL_TK_SRP-Werte, die in der Standardspielliste enthalten sind, während die kleinen Unterteilungen in den Kästen, die jede PLI darstellen, drei oder vier PL_TK_SRP-Werte darstellen. Die Einstellung von TKIN von jedem DPL_TK_SRP, der in der Standardspiellisteninformation enthalten ist, ist dieselbe wie in 40. Demgegenüber sind die Einstellungen von TKIN von PL_TK_SRP, der in jeder PLI enthalten ist, gänzlich von denjenigen in DPL_TK_SRP verschieden.
{17-10_42} Entsprechung zwischen DPL_TK_SRP und TKI
42 zeigt die Entsprechung zwischen DPL_TK_SRP und TKI unter Verwendung derselben Notation wie in 40. In 42 umfasst Playlist#1 PL_TK_SRP#1, #2, #3. Von diesen wird #3 als PL_TKIN von PL_TK_SRP#2 und #2 als PL_TKIN von PL_TK_SRP#3 geschrieben. Dies bedeutet, dass wenn Spuren entsprechend Playlist#1 abgespielt werden, eine Vielzahl von AOBs, wie durch die Pfeile (11), (12), (13) angedeutet ist, in der Reihenfolge AOB#3, AOB#1, AOB#2 abgespielt wird.
Playlist#2 umfasst PL_TK_SRP#1, #2, #3. Von diesen wird #8 als PL_TKIN von PL_TK_SRP#1 geschrieben, während #3 als PL_TKIN von PL_TK_SRP#2 und #1 als PL_TKIN von PL_TK_SRP#3 geschrieben werden. Dies bedeutet, dass wenn Spuren entsprechend Playlist#2 abgespielt werden, eine Vielzahl von AOBs, wie durch die Pfeile (21), 22), (23) angedeutet ist, in der Reihenfolge AOB#8, AOB#3, AOB#1, das heißt in einer gänzlich anderen Reihenfolge als Playlist#1 abgespielt wird.
Playlist#3 umfasst PL_TK_SRP#1, #2, #3, #4. PL_TKIN von PL_TK_SRP#1 bis #4 werden auf #8, #4, #3, #1 eingestellt. Dies bedeutet, dass wenn Spuren entsprechend Playlist#3 abgespielt werden, eine Vielzahl von AOBs folgendermaßen abgespielt wird. Zunächst wird AOB#8, das TrackE bildet, wie durch den Pfeil (31) gezeigt ist, abgespielt. Anschließend werden AOB#4, AOB#5, AOB#6 und AOB#7, die TrackD bilden, wie durch den Pfeil (32) gezeigt ist, abgespielt. Sodann werden AOB#3 und AOB#1, die TrackC beziehungsweise TrackA bilden, wie durch die Pfeile (33) und (34) gezeigt ist, abgespielt.
Von besonderem Interesse ist die Tatsache, dass für den Fall, dass eine Spur aus einer Vielzahl von TKIs zusammengesetzt ist, nur die TKI-Nummer des Anfangs der Spur in den PL_TK_SRP_Eintrag geschrieben wird. Dies bedeutet insbesondere, dass während die DPL_TK_SRP-Werte, die in Default_Playlist_Information gegeben sind, die vier TKIs (TKI#4, TKI#5, TKI#6, TKI#7), die TrackD bilden, spezifizieren, PL_TK_SRP gemäß Angabe in einem Satz von Playlist_Information nicht alle vier TKIs angeben muss. Aus diesem Grund gibt PL_TK_SRP#2 in Playlist#3 nur TKI#4 von TKI#4 bis TKI#7 an.
Demgegenüber weist DPLI mit einer Vielzahl von DK_TK_SRP eine Datengröße auf, die nicht größer als ein Sektor und immer in den RAM der Abspielvorrichtung geladen ist.
Werden Spuren entsprechend einer Spielliste abgespielt, so bezieht sich die Abspielvorrichtung auf DK_TK_SRPs, die in ihren RAM geladen sind, und kann somit mit hoher Geschwindigkeit nach TKIs suchen. Zum Abspielen von TKIs (AOBs) unter Verwendung von PL_TK_SRP, wodurch nur die TKI-Nummer der ersten TKI angegeben ist, sucht die Abspielvorrichtung DPL_TK_SRP gemäß Ladung in ihren RAM auf Grundlage von TKI gemäß Angabe durch PL_TK_SRP und beurteilt, ob die aktuelle Spur aus einer Vielzahl von TKIs zusammengesetzt ist. Ist dem so, so führt die Abspielvorrichtung die geeignete Prozedur zum Abspielen sämtlicher entsprechender TKIs (AOBs) aus.
Wie vorstehend beschrieben worden ist, werden Default_Playlist und eine Vielzahl von PLIs in den Spiellistenverwalter geschrieben. Werden verschiedene Abspielreihenfolgen in DPL_TKINs und PL_TKINs von DPL_TK_SRPs und PL_TK_SRPs, die diese Spiellisten bilden, geschrieben, so wird es möglich, AOBs in verschiedenen Reihenfolgen abzuspielen. Durch auf diese Weise erfolgendes Bereitstellen einer Vielzahl von Abspielreihenfolgen für den Anwender entsteht für den Anwender der Eindruck, dass eine Vielzahl von Musikalben auf der Flashspeicherkarte 31 gespeichert ist.
Von besonderem Interesse ist, dass die Datengröße von DPL_TK_SRP entsprechend einer AOB-Datei klein ist (nicht mehr als 2 Byte), während die Datengröße von TKI entsprechend einer AOB-Datei groß ist (bis zu 1024 Byte). Beim Aufzeichnen von TKI in dem Spurverwalter muss eine große Anzahl von Zugriffen auf die Flashspeicherkarte 31 vorgenommen werden, wohingegen dies beim Aufzeichnen von DPL_TK_SRPs in der Standardspiellisteninformation oder PLI mit weniger Zugriffen auf die Flashspeicherkarte 31 vorgenommen werden kann.
Eingedenk dessen wird bei einer Bearbeitung der Navigationsdaten die Reihenfolge von DPL_TK_SRPs in der Standardabspielliste aktiv entsprechend der Bearbeitungsoperation geändert, während die Reihenfolge von TKI im Spurverwalter ungeachtet der Bearbeitungsoperation unverändert gelassen wird.
{17-9-40-2_43A,B} Neuanordnen von DPL_TK_SRP
Nachfolgend wird eine Bearbeitungsoperation beschrieben, bei der die Abspielreihenfolge von Spuren durch Neuanordnen von DPL_TK_SRPs in der Standaedspiellisteninformation geändert wird. 43A und 43B zeigen ein Beispiel für das Neuanordnen von Spuren. Das Einstellen von DPL_TK_SRPs und TKIs in 43A ist dasselbe wie in 40.
Wie in 40A gezeigt ist, wird DPL_TKIN in DPL_TK_SRP#3 auf TKI#3 eingestellt, während DPL_TKIN in DPL_TK_SRP#8 auf TKI#8 eingestellt wird. Nachfolgend wird derjenige Fall beschrieben, in dem DPL_TK_SRPs in 40A mit dicker Umrisslinie vertauscht werden.
Die Nummern (1), (2), (3), (4), (5), (6), (7), (8) in 43B zeigen die Abspielreihenfolge der Spuren nach der Bearbeitungsoperation. Man beachte hierbei, dass obwohl die Abspielreihenfolge gemäß 43A gleich TrackA, TrackB, TrackC, TrackD, TrackE ist, in 43B DPL_TKINs von DPL_TK_SRP#3 und DPL_TK_SRP#8 in der Standardspiellisteninformation ausgetauscht werden, sodass die Spuren in der Reihenfolge TrackA, TrackB, TrackE, TrackD, TrackC abgespielt werden. Auf diese Weise kann die Abspielreihenfolge von Spuren einfach durch Ändern der Reihenfolge von DPL_TK_SRPs in der Standardspiellisteninformation geändert werden.
Während sich die vorstehende Beschreibung mit einer Bearbeitungsoperation befasst, die die Reihenfolge von Spuren ändert, werden nachfolgend vier Operationen beschrieben, die im Zusammenhang mit den Änderungen in TKIs bereits beschrieben worden sind. Diese Operationen betreffen einen ersten Fall (Fall 1), in dem eine Spur gelöscht wird, einen zweiten Fall (Fall 2), in dem eine neue Spur aufgezeichnet wird, einen dritten Fall (Fall 3), in dem zwei frei ausgewählte Spuren zu einer neuen Spur kombiniert werden, und einen vierten Fall (Fall 4), in dem eine Spur in zwei neue Spuren unterteilt wird.
{17-9_40-3_44A,B} Löschen einer Spur
Nachfolgend wird Fall 1 beschrieben, in dem eine Spur gelöscht wird.
44A und 44B zeigen, wie die Standardspielliste, der Spurverwalter und die AOB-Dateien aktualisiert werden, wenn aus der Standardspielliste von 40 DPL_TK_SRP#2 und TKI#2 gelöscht werden. In dieser Figur wird derselbe Teil von AOB wie in 27 gelöscht, anhand dessen die Beschreibung des Löschens von TKI erfolgt ist. Im Ergebnis sind die zweite, dritte und vierte Ebene in 44A und 44B dieselben wie in 27. Der Unterschied zu 24 besteht darin, dass eine DPL_TK_SRPs enthaltende Standardspiellisteninformation auf der ersten Ebene auf dieselbe Weise wie in 40 angegeben ist.
Das vorliegende Beispiel befasst sich mit dem Fall, in dem der Anwender TrackB löscht, der sich aus DPL_TK_SRP#2 → TKI#2 („AOB002.SA1") zusammensetzt, was in 44A mit dicker Umrisslinie gezeigt ist. In diesem Fall wird DPL_TK_SRP#2 aus der Standardspiellisteninformation gelöscht, und es werden DPL_TK_SRP#3 bis DPL_TK_SRP#8 jeweils um eine Stelle in der Abspielreihenfolge derart bewegt, dass sie die durch das Löschen von DPL_TK_SRP#2 freigewordene Stelle in der Reihenfolge einnehmen.
Werden DPL_TK_SRPs auf diese Weise weiter bewegt, so wird der letzte DPL_TK_SRP#8 auf „nicht verwendet" eingestellt. Demgegenüber wird TKI entsprechend einem gelöschten Teil auf „nicht verwendet", wie in 27A und 27B gezeigt ist, eingestellt, ohne dass andere TKIs in die durch das Löschen entstandene Lücke bewegt würden. Das Löschen von TKI geht zudem mit dem Löschen der AOB-Datei „AOB002.SA1" einher.
Auf diese Weise werden DPL_TK_SRPs in der Abspielliste bewegt, wobei jedoch TKIs nicht bewegt werden, sodass in 44B nur die DPL_TKINs in DPL_TK_SRPs aktualisiert werden. Bei diesem Beispiel wird DPL_TKIN in DPL_TK_SRP#2 derart eingestellt, dass TKI#3 angegeben ist, wie durch den Pfeil DT11 angegeben ist. DPL_TKIN in DPL_TK_SRP#3 wird derart eingestellt, dass TKI#4 angegeben ist, wie durch den Pfeil DT12 gezeigt ist. DPL_TKIN in DPL_TK_SRP#4 wird derart eingestellt, dass TKI#5 angegeben ist. DPL_TKIN in DPL_TK_SRP#5 wird derart eingestellt, dass TKI#6 angegeben ist. DPL_TKIN in DPL_TK_SRP#8 mit der Einstellung auf „nicht verwendet" wird derart eingestellt, dass TKI#2 angegeben wird, wie durch den Pfeil DT13 gezeigt ist.
Wird eine Spur gelöscht, so wird DPL_TK_SRP, der für die nachfolgenden Spuren in der Abspielreihenfolge verwendet wird, weiterbewegt, während TKI entsprechend der gelöschten Spur auf „nicht verwendet" gesetzt wird und in der aktuellen Position verbleibt. Auf diese Weise geht eine Bearbeitungsoperation nicht mit der Bewegung von TKIs einher, was die Verarbeitungsbelastung beim Bearbeiten von Spuren verringert.
{17-9_40-4_45A,B} Zuweisung von TKIs bei der Aufzeichnung von Spuren
Nachfolgend wird Fall 2 beschrieben, bei dem eine neue Spur im Gefolge einer teilweise erfolgenden Löschung einer Spur aufgezeichnet wird. 45A und 45B zeigen, wie eine Operation, bei der eine neue TKI und DPL_TK_SRP geschrieben werden, ausgeführt wird, wenn eine „nicht verwendete" TKI und DPL_TK_SRP vorhanden sind.
Diese Figuren sind weitgehend dieselben wie 28A und 28B, die zur Erläuterung der Zuweisung einer neuen TKI an eine TKI mit einer Einstellung auf „nicht verwendet" zum Einsatz gekommen sind. Die zweite, dritte und vierte Ebene in 45A und 45B sind dieselben wie die ersten drei Ebenen in 28A und 28B. Der Unterschied zwischen diesen Figuren besteht darin, dass die ersten Ebenen in 45A und 45B die Standardspiellisteninformation zeigen, die aus einer Vielzahl von DPL_TK_SRP#4 gebildet ist. In 45A sind DPL_TK_SRP#4 bis DPL_TK_SRP#8 auf „nicht verwendet" eingestellt. Demgegenüber sind in 28 TKI#2, TKI#4, TKI#5, TKI#7, TKI#8 auf „nicht verwendet" eingestellt. Während auf „nicht verwendet" eingestellte TKIs an manchen Stellen in dem Spurverwalter vorhanden sind, sind die „nicht verwendeten" DPL_TK_SRPs nebeneinander in der Standardspiellisteninformation angeordnet. Dies ergibt sich aus den verwendeten DPL_TK_SRPs, die in der Standardspiellisteninformation gemäß vorstehender Beschreibung weiterbewegt worden sind, wohingegen keine derartige Weiterbewegung bei den TKIs vorgenommen worden ist.
Nachfolgend wird derjenige Fall beschrieben, in dem TrackD, der sich aus vier AOBs zusammensetzt, geschrieben wird. Die TKIs für diese vier AOBs werden jeweils in die nachfolgenden „nicht verwendeten" TKIs in dem Spurverwalter geschrieben: TKI#2, TKI#4, TKI#7 und TKI#8.
Die DPL_TK_SRPs für diese vier AOBs werden in DPL_TK_SRP#4 bis DPL_TK_SRP#7 in der Standardspiellisteninformation geschrieben. Da diese vier AOBs eine einzige Spur bilden, sind DPL_TK_ATR von DPL_TK_SRP#4 auf „Head_of_Track", die DPL_TK_ATRs von DPL_TK_SRP#5 und DPL_TK_SRP#6 auf „Middle_of_Track" und DPL_TK_ATR von DPL_TK_SRP#7 auf „End_of_Track" eingestellt.
DPL_TKIN von DPL_TK_SRP#4 ist auf TKI#2, DPL_TKIN von DPL_TK_SRP#5 auf TKI#4, DPL_TKIN von DPL_TK_SRP#5 auf TKI#7 und DPL_TKIN von DPL_TK_SRP#7 auf TKI#8 eingestellt.
Durch das auf diese Weise erfolgende Einstellen von DPL_TKINs und DPL_TK_ATRs werden TKI#2, TKI#4, TKI#7 und TKI#8 als vierte Spur TrackD verwaltet.
Bei der nachfolgenden Verarbeitung wird ein Schreibvorgang für „nicht verwendete" TKIs vorgenommen, obwohl dies auf andere TKIs TKI#1, TKI#2, TKI#3 und TKI#4 keine Auswirkungen hat, wie dies auch im Zusammenhang mit 28A und 28B der Fall war.
{17-9_40-5_46A,B} Fall 3: Kombinieren von Spuren
Nachfolgend wird das Aktualisieren der Standardspiellisteninformation bei einer Kombination von Spuren (das heißt Fall 3) beschrieben. 46A und 46B zeigen ein Beispiel für das Kombinieren von Spuren.
Diese Figuren sind weitgehend dieselben wie 29A und 29B, die zur Erläuterung des Kombinierens von TKIs eingesetzt werden. Die zweite, dritte und vierte Ebene in 46A und 46B sind dieselben wie die ersten beiden Ebenen in 29A und 29B. Der Unterschied zwischen diesen Figuren besteht darin, dass die ersten Ebenen in 46A und 46B Standardspiellisteninformation zeigen, worin DPL_TK_SRP#8 auf „nicht verwendet" eingestellt und auf TKI#2 bezogen ist, das ebenfalls auf „nicht verwendet" eingestellt ist. Wenn ein Bearbeitungsvorgang zur einer Kombination von Spuren für AOB-Dateien und TKIs, wie in 29A und 29B gezeigt ist, ausgeführt wird, werden die Inhalte von DPL_TK_SRP#3 bis DPL_TK_SRP#6 jeweils um eines nach unten weiterbewegt, und der Inhalt von DPL_TK_SRP#7, der mit dicker Umrisslinie gezeichnet ist, wird, wie in 46A und 46B gezeigt ist, nach DPL_TK_SRP#3 kopiert. Die TKIs werden ebenfalls aktualisiert, wie in 29A und 29B gezeigt ist.
{17-9_40-6_47A,B} Fall 4: Unterteilen einer Spur
Nachfolgend wird das Aktualisieren der Standardspiellisteninformation beschrieben, wenn eine Spur unterteilt wird (Fall 4).
47A und 47B zeigen ein Beispiel für das Unterteilen einer Spur. Diese Figuren sind weitgehend dieselben wie 33A und 33B, die zur Erläuterung der Unterteilung der TKIs verwendet worden sind. Die zweite und dritte Ebene in 47A und 47B sind dieselben wie die ersten beiden Ebenen in 33A und 33B. Der Unterschied zwischen diesen Figuren besteht darin, dass die erste Ebene in 47A und 47B Standardspiellisteninformation zeigt, worin DPL_TK_SRP#8 auf „nicht verwendet" eingestellt und auf TKI#2 bezogen ist, das ebenfalls auf „nicht verwendet" eingestellt ist.
Wenn, wie in 33A und 33B gezeigt ist, der Anwender das Unterteilen von TKI#3 („AOB003.SA1"), die mit einer dicken Umrisslinie gezeigt ist, in zwei angibt, werden die Positionen von DPL_TK_SRP#3 bis DPL_TK_SRP#7 jeweils um eins in der Reihenfolge weiter nach unten bewegt, und DPL_TK_SRP mit der Einstellung auf „nicht verwendet" wird innerhalb der Spiellisteninformation auf die frühere Position von DPL_TK_SRP#3 bewegt.
Dieser neue DPL_TK_SRP#3 ist mit TKI, TKI#2 der Neuerzeugung durch die Teilung verknüpft. Die AOB-Datei „AOB002.SA1" in Verknüpfung mit TKI#2 speichert, was ursprünglich der letztere Teil der AOB-Datei „AOB003.SA1" war. DPL_TK_SRP#2 ist vor DPL_TK_SRP#3, der mit TKI#2 verknüpft ist, vorhanden und mit TKI#2 und „AOB002.SA1" verknüpft.
Dies bedeutet, dass „AOB002.SA1" und „AOB003.SA1" die ersteren beziehungsweise letzteren Teile der ursprünglichen Datei „AOB003.SA1" speichern, wobei DPL_TK_SRP#2 und DPL_TK_SRP#3 diesen Dateien entsprechen, wodurch angegeben wird, dass diese AOBs in der Reihenfolge „AOB003.SA1" und „AOB002.SA1" abgespielt werden sollen. Im Ergebnis werden die letzteren und die ersteren Teile der ursprünglichen Datei „AOB003.SA1" in der Reihenfolge „ersterer Teil", „letzterer Teil" entsprechend der in DPL_TK_SRP angegebenen Abspielreihenfolge abgespielt.
{17-9_40-8} Anwenden einer Bearbeitungsverarbeitung
Durch Kombinieren der vorstehend beschriebenen vier Bearbeitungsprozesse können einem Anwender eine Vielzahl von Bearbeitungsoperationen geboten werden. Weist beispielsweise eine aufgezeichnete Spur eine Einleitung auf, über die ein Moderator gesprochen hat, so kann der Anwender zunächst die Spur derart unterteilen, dass der die Stimme des Moderators enthaltende Teil abgespalten wird. Der Anwender kann dann diese Spur löschen, sodass die erteilte Spur zurückbleibt, die den Moderator nicht enthält.
Dies beendet die Erläuterung der Navigationsdaten. Nachfolgend wird eine Abspielvorrichtung mit geeigneter Zusammensetzung zum Abspielen der Navigationsdaten und der Präsentationsdaten gemäß vorstehender Beschreibung beschrieben.
{48-1} Aussehen der Abspielvorrichtung
48 zeigt eine tragbare Abspielvorrichtung für eine Flashspeicherkarte 31 der vorliegenden Erfindung. Die Abspielvorrichtung, die in 48 gezeigt ist, weist einen Eingabeschlitz zum Einführen der Flashspeicherkarte 31, ein Tastenfeld zum Empfangen von Anwenderanweisungen für Operationen wie Abspielen, Vorwärtssuche, Rückwärtssuche, Schnellvorwärtslauf, Rücklauf, Stopp und dergleichen mehr sowie ein LCD-Feld (Flüssigkristallanzeige) auf. Was das Aussehen angeht, so ist diese Abspielvorrichtung anderen Arten von tragbaren Musikabspielgeräten ähnlich.
Das Tastenfeld umfasst:

• eine Taste „Spielliste" (Playlist), die die Auswahl einer Spielliste oder einer Spur annimmt;
• eine Taste „|<<", die eine Überspringoperation annimmt, die die Abspielposition auf den Anfang der aktuellen Spur bewegt;
• eine Taste „>>|", die eine Überspringoperation annimmt, die die Abspielposition auf den Anfang der nächsten Spur bewegt;
• eine Taste „<<" und eine Taste „>>", die eine Vorwärtssuchoperation beziehungsweise eine Rückwärtssuchoperation annehmen, die einen Anwender in die Lage versetzen, das Abspielen durch die aktuelle Spur schnell ablaufen zu lassen;
• eine Taste „Anzeigen" (Display), die eine Operation annimmt, bei der auf der Flashspeicherkarte 31 gespeicherte Standbilder angezeigt werden;
• eine Taste „Rec", die eine Aufzeichnungsoperation annimmt;
• eine Taste „Audio", die Anwenderanweisungen bezüglich der Abtastfrequenz oder der Verwendung von stereo oder mono annimmt;
• eine Taste „Mark", die Anwenderanweisungen annimmt, wonach Positionen in Spuren markiert werden sollen; und
• eine Taste „Bearbeiten" (Edit), die Anwenderanweisungen zum Bearbeiten von Spuren oder zur Eingabe von Titeln von Spuren annimmt.

{48-2} Verbesserungen an der tragbaren Abspielvorrichtung mit Blick auf die Flashspeicherkarte 31
Die Unterschiede zwischen dieser tragbaren Abspielvorrichtung für die Flashspeicherkarte 31 und einem herkömmlichen tragbaren Musikabspielgerät betreffen die nachfolgend aufgeführten vier Verbesserungen (1) bis (4).

(1) Eine Liste von Spiellisten und Spuren wird in dem LCD-Feld gezeigt, wodurch der Anwender in die Lage versetzt wird, die Standardspiellisteninformation, PLI oder getrennte Spuren anzugeben.
(2) Tasten in dem Tastenfeld sind Spiellisten und/oder Spuren, die in dem LCD-Feld angezeigt werden, zugewiesen, wodurch der Anwender in die Lage versetzt wird, eine Spur oder Spielliste, die abgespielt oder bearbeitet werden soll, auszuwählen.
(3) Es wird ein Zeitcode, der eine Position in einer Spur zeigt, in dem LCD-Feld 5 angezeigt, wenn eine Spur abgespielt wird.
(4) Es ist eine Drehscheibe (jog dial) vorgesehen, die den Anwender in die Lage versetzt, einen Zeitcode zur Verwendung als Abspielstartzeit bei der Verwendung der Zeitsuchfunktion oder als Unterteilungsgrenze beim Unterteilen einer Spur einzusetzen.

{48-2_49_50} Verbesserung (2)
Nachfolgend wird Verbesserung (2) detailliert beschrieben.
49 zeigt ein Beispiel für einen Anzeigeschirm, der in dem LCD-Feld angezeigt wird, wenn der Anwender eine Spielliste auswählt, während 50A und 50B Beispiele für die angezeigten Inhalte angeben, wenn der Anwender eine Spur auswählt.
In 49 bezeichnen die Aufschriften „DEFAULTPLAYLIST" (Standardspielliste), „PLAYLIST#1" (Spielliste #1), „PLAYLIST#2" (Spielliste #2), „PLAYLIST#3" (Spielliste #3) und „PLAYLIST#4" (Spielliste #4) die Standardspielliste und die vier auf der Flashspeicherkarte 31 gespeicherten Spiellisten.
Die Aufschriften „Track#1" (Spur #1), „Track#2" (Spur #2), „Track#3" (Spur #3), „Track #4" (Spur #4) und „Track#5" (Spur #5) bezeichnen die fünf Spuren, die in der Spiellistenreihenfolge gemäß Vorgabe durch die Standardspielliste aus der Speicherung auf der Flashspeicherkarte 31 angegeben sind. Wie in 49 und 50A gezeigt ist, zeigen die markierte Spielliste und die markierte Spur diejenige Spur oder Spielliste, die aktuell zum Abspielen und Bearbeiten angezeigt sind.
Drückt der Anwender die Taste „>>", wenn Track#1 zum Abspielen innerhalb einer Abspielreihenfolge gemäß Vorgabe durch die Standardspielliste aus der Anzeige auf dem LCD-Feld angegeben ist, so wird Track#2 zum Abspielen innerhalb der Liste von Spuren angezeigt, wie in 50B gezeigt ist. Drückt der Anwender die Taste „>>" erneut, so wird Track#3 zum Abspielen innerhalb der Liste von Spuren angezeigt, wie in 50C gezeigt ist.
Drückt der Anwender die Taste „<<", wenn Track#3 zum Abspielen innerhalb einer Abspielreihenfolge gemäß Vorgabe durch die Standardspielliste aus der Anzeige auf dem LCD-Feld angezeigt ist, so wird Track#2 zum Abspielen innerhalb der Liste von Spuren angezeigt, wie in 50D gezeigt ist. Wie in 50E gezeigt ist, beginnt, wenn der Anwender die Taste „Play" (Spielen) drückt, wenn eine beliebige Spur angezeigt wird, das Abspielen der angezeigten Spur erneut, wohingegen für den Fall, dass der Anwender die Taste „Edit" (Bearbeiten) drückt, die angegebene Spur zur Bearbeitung ausgewählt wird.
{48-3_51} Verbesserung (4)
Nachfolgend wird Verbesserung (4) detailliert beschrieben. 51A bis 51C zeigen eine Beispielsoperation für die Drehscheibe (jog dial). Dreht der Anwender die Drehscheibe um einen bestimmten Betrag, so wird der Abspielzeitcode gemäß Anzeige in dem LCD-Feld entsprechend diesem Betrag erhöht oder erniedrigt. Das in 51A gezeigte Beispiel zeigt denjenigen Fall, in dem der Abspielzeitcode, der anfänglich in dem LCD-Feld angezeigt ist, gleich „00:00:20" ist.
Dreht der Anwender die Drehscheibe gegen den Uhrzeigersinn, wie in 51B gezeigt ist, so wird der Abspielzeitcode auf „0:00:10" verringert, was dem Betrag entspricht, um den die Drehscheibe gedreht wurde. Dreht im umgekehrten Fall der Anwender die Drehscheibe im Uhrzeigersinn, wie in 51C gezeigt ist, so wird der Abspielzeitcode entsprechend dem Betrag, um den die Drehscheibe gedreht wurde, auf „0:00:30" erhöht.
Indem der Anwender in die Lage versetzt wird, den Abspielzeitcode auf diese Weise zu verändern, ermöglicht die Abspielvorrichtung dem Anwender, einen bestimmten Abspielzeitcode in einer Spur dadurch anzugeben, dass die Drehscheibe gedreht wird. Drückt der Anwender anschließend die Taste "Play" (Spielen), so werden AOBs beginnend mit einer Position gemäß Berechnung durch Gleichungen 2 und 3 abgespielt.
Durch Verwendung der Drehscheibe während einer Spurunterteilungsoperation kann der Anwender feinere Einstellungen an dem Abspielzeitcode, der als Unterteilungsgrenze verwendet wird, vornehmen.
{52-1} Interner Aufbau der Abspielvorrichtung
Nachfolgend wird der interne Aufbau der Abspielvorrichtung beschrieben. Der interne Aufbau ist in 52 gezeigt.
Wie in 52 gezeigt ist, umfasst die Abspielvorrichtung einen Kartenanschluss 1 zum Verbinden der Abspielvorrichtung mit der Flashspeicherkarte 31, eine Anwenderschnittstelleneinheit 2 zum Verbinden mit dem Tastenfeld und der Drehscheibe, einen RAM 3, einen ROM 4, ein LCD-Feld 5 mit einem Listenrahmen zum Anzeigen einer Liste von Spuren oder Spiellisten und einem Abspielzeitcoderahmen zum Anzeigen eines Abspielzeitcodes, einen LCD-Treiber 6 zum Betreiben des ersten LCD-Feldes 5, einen Entwürfler 7 (descrambler) zum Entschlüsseln von AOB_FRAMEs unter Verwendung eines anderen FileKey für jede AOB-Datei, einen AAC-Decodierer 8 zum Verweisen auf ADTS eines AOB_FRAME nach der Entwürflung durch den Entwürfler 7 und Decodieren von AOB_FRAME zur Ermittlung von PCM-Daten, einen Digital-Analog-Wandler 9 zur Digital-Analog-Wandlung der PCM-Daten und Ausgeben der sich ergebenden analogen Signale an einen Lautsprecher oder einen Kopfhörer und eine CPU 10 zur Vornahme einer Gesamtsteuerung der Abspielvorrichtung.
Der vorbeschriebene Hardwareaufbau macht deutlich, dass die vorliegende Abspielvorrichtung keine speziellen Hardwareelemente zum Verarbeiten des Spurverwalters und der Standardspiellisteninformation aufweist. Zur Verarbeitung des Spurverwalters und der Standardspiellisteninformation sind ein DPLI-Vorhaltegebiet 11, ein PLI-Speichergebiet 12, ein TKI-Speichergebiet 13, ein FileKey-Speichergebiet 14 und ein Doppelpuffer 15 in dem RAM 3 vorgesehen, während ein Abspielsteuerprogramm und ein Bearbeitungssteuerprogramm in dem ROM 4 gespeichert sind.
{52_2} DPLI-Vorhaltegebiet 11
Das DPLI-Vorhaltegebiet 11 ist ein Gebiet zum kontinuierlichen Vorhalten der Standardspiellisteninformation, die von einer Flashspeicherkarte 31, die mit dem Kartenanschluss 1 verbunden ist, gelesen worden ist.
{52_12} PLI-Speichergebiet 12
Das PLI-Speichergebiet 12 ist ein Gebiet, das für das Speichern von Spiellisteninformation, die vom Anwender zum Abspielen ausgewählt worden ist, reserviert ist.
{52_3} TKI-Speichergebiet 13
Das TKI-Speichergebiet 13 ist ein Gebiet, das nur für das Speichern der_TK_entsprechend der AOB-Datei reserviert ist, die aktuell zum Abspielen angezeigt ist, aus der Vielzahl von in dem Spurverwalter enthaltenen TKIs. Aus diesem Grund ist die Kapazität des TKI-Speichergebietes 13 gleich der Datengröße einer TKI.
{52_4} FileKey-Speichergebiet 14
Das FileKey-Speichergebiet 14 ist ein Gebiet, das nur für das Speichern des Filekey entsprechend der AOB-Datei reserviert ist, die aktuell zum Abspielen angezeigt ist, aus der Vielzahl von FileKeys, die in „AOBSA1.KEY" in dem Authentisierungsbereich enthalten sind.
{52_5} Doppelpuffer 15
Der Doppelpuffer 15 ist ein Eingabe-/Ausgabe-Puffer, der verwendet wird, wenn ein Eingabeprozess, bei dem aufeinanderfolgend Eingabedaten (Daten, die in einem Cluster gespeichert sind), die von der Flashspeicherkarte 31 gelesen werden, und ein Ausgabeprozess, bei dem AOB_FRAMEs aus den Clusterdaten gelesen und die AOB_FRAMEs anschließend an den Entwütfler 7 ausgegeben werden, parallel ausgeführt werden.
Der Doppelpuffer 15 legt aufeinanderfolgend diejenigen Bereiche frei, die von Clusterdaten belegt gewesen sind, die als AOB_FRAMEs ausgegeben worden sind, und sichert so Bereiche zum Speichern der nächsten zu lesenden Cluster. Dies bedeutet, dass Bereiche in dem Doppelpuffer 15 zyklisch zum Speichern von Clusterdaten unter Verwendung von Ringzeigern (ring pointers) gesichert werden.
{52-5_53_54A,B} Eingabe und Ausgabe durch den Doppelpuffer 15
53 zeigt, wie die Eingabe und Ausgabe an dem Doppelpuffer 15 vorgenommen wird. 54A und 54B zeigen, wie Bereiche in dem Doppelpuffer 15 zyklisch zum Speichern von Clusterdaten unter Verwendung von Ringzählern gesichert werden.
Die nach unten und nach links weisenden Teile sind Zeiger zum Schreiben von Adressen für Clusterdaten. Dies bedeutet, dass es sich hierbei um den Schreibzeiger handelt. Die nach oben und links weisenden Pfeile sind Zeiger zum Lesen von Adressen für Clusterdaten, was bedeutet, dass es sich um den Lesezeiger handelt. Die Zeiger werden als Ringzeiger verwendet.
{54-6_53}
Wird eine Flashspeicherkarte 31 mit dem Kartenanschluss 1 verbunden, so werden Clusterdaten in dem Anwendungsbereich der Flashspeicherkarte 31 ausgelesen und in dem Doppelpuffer 15, wie durch die Pfeile w1 und w2 gezeigt ist, gespeichert.
Die gelesenen Clusterdaten werden aufeinanderfolgend in Positionen in dem Doppelpuffer 15 gespeichert, die durch die Schreibzeiger wp1 und wp2 bezeichnet sind.
{52-7_54A}
Von den AOB_Frames in den Clusterdaten, die auf diese Weise gespeichert worden sind, werden diejenigen AOB_Frames, die an den Positionen (1), (2), (3), (4), (5), (6), (7), (8), (9) vorhanden sind, die aufeinanderfolgend durch den Lesezeiger angezeigt werden, jeweils an den Entwürfler 7 ausgegeben, wie durch die Pfeile r1, r2, r3, r4, r5 ... dargestellt ist.
Im vorliegenden Fall sind die Clusterdaten 002 und 003 in dem Doppelpuffer 15 gespeichert, und die Lesepositionen (1), (2), (3), (4) werden aufeinanderfolgend von dem Lesezeiger angezeigt, wie in 53 gezeigt ist. Erreicht der Lesezeiger die Leseposition (5), so sind sämtliche in dem Cluster 002 enthaltenen AOB_FRAMEs gelesen worden, sodass nun das Cluster 004 gelesen und, wie durch den Pfeil w6 in 54 angezeigt ist, in denjenigen Bereich überschrieben wird, der vorher von dem Cluster 002 belegt war.
{52-8_54B}
Der Lesezeiger rückt anschließend in die Lesepositionen (6) und (7) vor und erreicht gegebenenfalls die Leseposition (9), wobei an diesem Punkt sämtliche AOB_FRAMEs, die in dem Cluster 003 enthalten sind, gelesen worden sind, sodass nun das Cluster 005 gelesen und, wie durch den Pfeil w7 in 54B angedeutet ist, in denjenigen Bereich, der vorher von dem Cluster 003 belegt war, überschrieben wird.
Die Ausgabe von AOB_FRAME und das Überschreiben von Clusterdaten werden, wie vorstehend beschrieben worden ist, wiederholt ausgeführt, sodass die in einer AOB-Datei enthaltenen AOB_FRAMEs alle aufeinanderfolgend an den Entwürfler 7 und den AAC-Decodierer 8 ausgegeben werden.
{52-9_55-58} In dem RAM 4 gespeichertes Abspielsteuerprogramm
Nachfolgend wird das Abspielsteuerprogramm, das in dem RAM 4 gespeichert ist, beschrieben.
55 ist ein Flussdiagramm, das die Verarbeitung bei der AOB-Dateileseprozedur beschreibt. 56, 57 und 58 sind Flussdiagramme, die die Verarbeitung bei der AOB_FRAME-Ausgabeprozedur zeigen.
{52-9_55-1}
Die Flussdiagramme bedienen sich der Variablen w, z, y und x. Die Variable w bezeichnet einen Wert aus der Vielzahl von DPL_TL_SRPs. Die Variable z bezeichnet eine AOB-Datei, die in dem Anwenderbereich aufgezeichnet ist, wobei TKI dieser AOB-Datei entspricht und AOB in dieser AOB-Datei enthalten ist. Die Variable y bezeichnet AOB_ELEMENT, das in AOB#z enthalten ist, das mit der Variable z bezeichnet ist. Die Variable x bezeichnet AOB_FRAME, das in AOB_ELEMENT#y enthalten ist, das mit der Variable y bezeichnet ist. Nachfolgend wird zunächst die Verarbeitung bei der AOB-Dateileseprozedur anhand 55 beschrieben.
{52-9_55-1}
In Schritt S1 liest die CPU 10 den Spiellistenverwalter und zeigt eine Liste an, die die Standardspiellisteninformation und die PLIs enthält.
In Schritt S2 wartet die CPU auf eine Anweisung zum Abspielen von AOBs entsprechend dem Umstand, ob die Standardspiellisteninformation oder eine der PLIs angegeben worden ist.
Für den Fall, dass die Standardspiellisteninformation angegeben ist, bewegt sich die Verarbeitung von Schritt S2 zu Schritt S3, wo die Variable w initialisiert wird (#w ← 1), und anschließend zu Schritt S4, wo TKI#z, das durch DPL_TKIN entsprechend DPL_TK_SRP#w in der Standardspiellisteninformation angegeben ist, spezifiziert wird, wobei nur dieses TKI#z von dem Flashkartenspeicher 31 gelesen und in dem TKI-Speichergebiet 13 gespeichert wird.
In Schritt S5 wird eine AOB-Datei #z (AOB file#z) mit derselben Nummer wie TKI#z spezifiziert. Auf diese Weise wird die AOB-Datei, die abgespielt wird, schließlich spezifiziert.
Die spezifizierte AOB-Datei befindet sich im verschlüsselten Zustand und muss entschlüsselt werden, weshalb die Schritte S6 und S7 ausgeführt werden. In Schritt S6 greift die Abspielvorrichtung auf den Authentisierungsbereich zu und liest FileKey#z aus, der in FileKey_Entry#z in der Verschlüsselungsschlüsselspeicherdatei gespeichert ist, wobei FileKey_Entry#z dieselbe Nummer wie die spezifizierte AOB-Datei aufweist. In Schritt S7 stellt die CPU 10 FileKey#z in dem Entwürfler 7 ein. Die Operation führt dazu, dass der FileKey in dem Entwürfler eingestellt ist, sodass durch aufeinanderfolgende Eingabe von AOB_FRAMEs, die in der AOB-Datei enthalten sind, in den Entwürfler 7 AOB_FRAMEs aufeinanderfolgend abgespielt werden können.
{52-9_55-3}
Anschließend liest die Abspielvorrichtung aufeinanderfolgend die Cluster, die die AOB-Datei speichern. In Schritt S8 wird die „erste Clusternummer in der Datei" für AOB_file#z in dem Verzeichniseintrag spezifiziert. In Schritt S9 liest die CPU 10 die in diesem Cluster gespeicherten Daten von der Flashspeicherkarte 31. In Schritt S11 beurteilt die CPU 10 den Umstand, ob die Clusternummer in dem FAT-Wert gleich „FFF" ist. Ist dem nicht so, so liest die CPU in Schritt S11 die in dem Cluster gemäß Angabe durch den FAT-Wert gespeicherten Daten und kehrt sodann zu Schritt S10 zurück.
Liest die Abspielvorrichtung die in einem beliebigen der Cluster gespeicherten Daten und nimmt Bezug auf den FAT-Wert entsprechend diesem Cluster, so wird die Verarbeitung in Schritten S10 und S11 wiederholt, solange der FAT-Wert nicht auf „FFF" eingestellt ist. Dies führt dazu, dass die Verarbeitungsvorrichtung aufeinanderfolgend Cluster gemäß Angabe durch die FAT_Werte liest. Ist die Clusternummer gemäß Angabe durch einen FAT-Wert gleich „FFF", so bedeutet dies, dass sämtliche Cluster, die AOB file#z bilden, gelesen worden sind, weshalb die Verarbeitung von Schritt S10 zu S12 übergeht.
{52-9_55-4}
In Schritt S5 beurteilt die CPU 10 den Umstand, ob die Variable #w der Gesamtzahl von DPL_TK_SRPs entspricht. Ist dem nicht so, so geht die Verarbeitung zu Schritt S13 über, wo die Variable #w inkrementiert wird (#w ← #w + 1), bevor die Verarbeitung zu Schritt S4 zurückkehrt. In Schritt S4 spezifiziert die Abspielvorrichtung TKI#z, die durch DPL_TKIN#w von DPL_TK_SRP#w in der Standardspiellisteninformation angegeben ist, und schreibt nur TKI#z in das TKI-Speichergebiet 13. Die TKI, die bis zu diesem Punkt verwendet worden ist, ist immer noch in dem TKI-Speichergebiet 13 gespeichert, obwohl diese aktuelle TKI durch TKI#z überschrieben wird, die von der CPU 10 neu gelesen wird.
Dieses Überschreiben führt dazu, dass nur die aktuelle TKI in dem TKI-Speichergebiet 13 gespeichert ist. Sobald die TKI überschrieben ist, wird die Verarbeitung in Schritten S5 bis S12 für AOB file#z wiederholt. Sobald die Verarbeitung sämtliche TKI und AOB-Dateien entsprechend sämtlichen DPL_TK_SRPs, die in der Standardspiellisteninformation enthalten sind, gelesen hat, entspricht die Variable #z der Gesamtzahl von DPL_TK_SRP, weshalb die Bewertung „Ja" in Schritt S12 gegeben wird und die Verarbeitung in diesem Flussdiagramm endet.
{52-9_56_57_58} Ausgabeverarbeitung für AOB_FRAME
Parallel zur Prozedur des Lesens der AOB-Datei nimmt die CPU die Prozedur des Ausgebens von AOB_FRAME entsprechend den Flussdiagrammen vor, die in 56, 57 und 58 gezeigt sind. In diesen Flussdiagrammen zeigt die Variable „play_time" (Spielzeit), wie lange das Abspielen bei der aktuellen Spur erfolgt ist, das heißt, es zeigt den Abspielzeitcode. Die Zeit, die in dem Abspielzeitcoderahmen in dem LCD-Feld 5 angezeigt wird, wird entsprechend den Änderungen an dem Abspielzeitcode aktualisiert. Zwischenzeitlich stellt die Variable „play data" (Spieldaten) die Länge der Daten dar, die bei der aktuellen Spur abgespielt worden sind.
{52-9_56-1}
In Schritt S21 überwacht die CPU 10, ob sich Clusterdaten für AOB file#z in dem Doppelpuffer 15 angesammelt haben. Schritt S21 wird wiederholt ausgeführt, bis sich die Clusterdaten angesammelt haben, wobei an diesem Punkt die Verarbeitung zu Schritt S22 übergeht, wo die Variablen x und y initialisiert werden (#x ← 1, #y ← 1). Anschließend durchsucht die CPU 10 in Schritt S23 die Cluster nach AOB file#z und erfasst AOB_FRAME#x in AOB_ELEMENT#y, das nicht vor Data Offset gemäß Angabe in BIT#z, das in TKI#z enthalten ist, angeordnet ist. Bei diesem Beispiel wird davon ausgegangen, dass die sieben Byte ausgehend von SZ_DATA von dem ADTS-Header belegt sind. Durch Bezugnahme auf den ADTS-Header kann die Datenlänge, die durch den ADTS-Header angegeben ist, als Audiodaten erkannt werden. Die Audiodaten und der ADTS-Header werden zusammen gelesen und an den Entwürfler 7 ausgegeben. Der Entwürfler 7 entschlüsselt die AOB_FRAMEs, die anschließend von dem AAC-Decodierer 8 decodiert und als Audio (Ton) wiedergegeben werden können.
{52-9_56-2}
Nach dieser Erfassung wird in Schritt S24 AOB_FRAME#x an den Entwürfler 7 ausgegeben. In Schritt S25 werden die Variable play_time um die Abspieldauer von AOB_FRAME#x und die Variable play_data um eine Datenmenge entsprechend AOB_FRAME#x inkrementiert. Da die Abspielzeit von AOB_FRAME im vorliegenden Fall 20 ms beträgt, werden 20 ms zu der Variable „play_time" addiert.
Sobald der erste AOB_FRAME an den Entwürfler 7 ausgegeben ist, nimmt die Abspielvorrichtung in Schritt S26 Bezug auf den ADTS-Header von AOB_FRAME#x und spezifiziert, wo der nächste AOB_FRAME ist. In Schritt S27 inkrementiert die Abspielvorrichtung die Variable #x (#x ← #x + 1) und stellt AOB_FRAME#x als nächsten AOB_FRAME#x ein. In Schritt S28 wird AOB-FRAME#x in den Entwürfler 7 eingegeben.
Anschließend wird in Schritt S29 die Variable play_time um die Abspieldauer von AOB_FRAME#x inkrementiert, und es wird die Variable play_data um die Datenmenge entsprechend AOF_FRAME#x inkrementiert. Nach dem Inkrementieren von AOB_FRAME#x beurteilt die CPU 10 in Schritt S30, ob die Variable #x den in FNs_1st_TMSRTE gegebenen Wert erreicht hat.
Hat die Variable #x den Wert in FNs_1st_TMSRTE nicht erreicht, so prüft die Abspielvorrichtung in Schritt S31, ob der Anwender eine bestimmte Taste außer der Taste „Play" gedrückt hat, und kehrt anschließend zu Schritt S26 zurück. Die Abspielvorrichtung wiederholt anschließend die Verarbeitung von Schritten S26 bis S31, bis die Variable #x den Wert in FNs 1st TMSRTE erreicht hat oder bis der Anwender eine Taste außer der Taste „Play" drückt.
Drückt der Anwender eine Taste außer der Taste „Play", so endet die Verarbeitung in diesem Flussdiagramm, und es erfolgt eine geeignete Verarbeitung auf Grundlage der gedrückten Taste. Ist die gedrückte Taste die Taste „Stopp", so endet die Abspielprozedur. Ist die gedrückte Taste die Taste „Pause" (Anhalten), so wird das Abspielen angehalten.
{52-9_57-1}
Erreicht demgegenüber die Variable #x den Wert FNs_1st_TMSRTE, so wird die Bewertung „Ja" in Schritt S30 gegeben, und die Verarbeitung geht zu Schritt S32 in 57 über. Da sämtliche in dem aktuellen AOB_ELEMENT enthaltenen AOB_FRAMEs in der Verarbeitung zwischen Schritt S26 bis S30 in den Entwürfler 7 eingegeben worden sind, wird die Variable #y in Schritt S32 derart inkrementiert, dass das nächste AOB_ELEMENT als Datum zur Verarbeitung eingestellt wird, und es wird die Variable #x initialisiert (#y ← #y + 1, #x ← 1).
Anschließend bezieht sich die Abspielvorrichtung in Schritt S33 auf TKTMSRT und berechnet die erste Adresse von AOB_ELEMENT#y.
Die Abspielvorrichtung führt anschließend die Prozedur aus, die von Schritten S34 bis S42 gebildet wird. Bei dieser Prozedur werden die AOB_FRAMEs, die in AOB_ELEMENT enthalten sind, aufeinanderfolgend gelesen, weshalb die Aussage gerechtfertigt scheint, dass eine Ähnlichkeit zu derjenigen Prozedur besteht, die von Schrit ten S24 bis S31 gebildet wird. Der Unterschied zu der von Schritten S24 bis S31 gebildeten Prozedur betrifft die Bedingung, durch die die von den Schritten S24 bis S31 gebildete Prozedur endet und die in der Frage besteht, ob die Variable #x den durch FNs_1st_TMSRTE gezeigten Wert erreicht hat, während die Bedingung, durch die die von Schritt S34 bis Schritt S42 gebildete Prozedur endet, in der Frage besteht, ob die Variable #x den durch „FNs_Middle_TMRRTE" gezeigten Wert erreicht hat.
Erreicht die Variable #x den durch „FNs_Middle_TMSRTE" angezeigten Wert, so endet die von Schritten S34 bis S42 gebildete Schleifenprozedur, es wird in Schritt S41 die Bewertung „Ja" gegeben, und die Verarbeitung geht zu Schritt S43 über. In Schritt S43 inkrementiert die CPU 10 die Variable #y und initialisiert die Variable #x (#y ← #y + 1, #x ← 1). Anschließend wird in Schritt S44 die Variable y dahingehend bewertet, ob die Variable #y einen Wert erreicht hat, der kleiner oder gleich dem Gesamtwert TMSRT_entry_Number (TotalTMSRT_entry_Number) in TMSRT_Header in TKI#z ist.
Ist die Variable #y kleiner als (TotalTMSRT_entry_Number – 1), so ist AOB_ELEMENT#y nicht das letzte AOB_ELEMENT, sodass die Verarbeitung von Schritt S44 zu Schritt S32 zurückkehrt und die Schleifenprozedur von Schritt S32 bis Schritt S42 ausgeführt wird. Erreicht die Variable #y den Wert (TotalTMSRT_entry_Number – 1), so ist davon auszugehen, dass die Leseprozedur bis zum vorletzten AOB_ELEMENT fortgeschritten ist, sodass in Schritt S44 die Bewertung „Ja" gegeben wird und die Verarbeitung zu Schritt S45 in 58 übergeht.
{52-9_57-2}
Die aus Schritten S45 bis S54 gebildete Prozedur ähnelt der von Schritten S33 bis S42 gebildeten Prozedur dahingehend, dass jedes AOB_FRAME in dem letzten AOB_ELEMENT gelesen wird.
Der Unterschied zu der von Schritten S33 bis S42 gebildeten Prozedur besteht darin, dass während die von Schritten S33 bis S42 gebildete Schleifenprozedur endet, wenn in Schritt S41 die Bewertung erfolgt, dass die Variable #x den Wert in „FNs_Middle_TMSRTE" erreicht hat, die von Schritten S45 bis S54 gebildete Schleifenprozedur endet, wenn in Schritt S53 die Bewertung erfolgt, dass die Variable #x den Wert in „FNs_Last_TMSRTE" erreicht hat und die Variable play_data, die die Größe der Daten zeigt, die bislang gelesen worden sind, den als „SZ_DATA" gegebenen Wert erreicht hat.
Die von Schritten S49 bis S54 gebildete Prozedur wird wiederholt, bis die Bedingungen in Schritt S53 erfüllt sind, wobei an diesem Punkt in Schritt S53 die Bewertung „Ja" gegeben wird und die Verarbeitung zu Schritt S55 übergeht. In Schritt S55 inkrementiert die CPU 10 die Variable #z (#z ← #z +1), bevor die Verarbeitung zu Schritt S21 übergeht, wo die CPU 10 darauf wartet, dass sich die nächste AOB-Datei in dem Doppelpuffer 15 ansammelt. Sobald dies geschieht, geht die Verarbeitung zu Schritt S22 über, und die von Schritten S22 bis S54 gebildete Prozedur wird wiederholt. Dies bedeutet, dass die von DPL_TKIN des nächsten DPL_TK_SRP angegebene TKI spezifiziert wird und die AOB-Datei entsprechend dieser TKI, das heißt die AOB-Datei mit derselben Nummer wie TKI, spezifiziert wird.
Anschließend greift die Abspielvorrichtung auf den Authentisierungsbereich zu und spezifiziert denjenigen FileKey von den FileKeys in der Verschlüsselungsschlüsselspeicherdatei, der dieselbe Nummer wie TKI aufweist, bevor das Lesen dieses FileKey und das Einstellen desselben in dem Entwürfler 7 erfolgen. Im Ergebnis werden die AOB_FRAMEs, die in der AOB-Datei mit derselben Nummer wie TKI enthalten sind, aufeinanderfolgend gelesen und abgespielt.
{52-9_57-3_59} Aktualisieren des Abspielzeitcodes
59A bis 59D zeigen, wie der Abspielzeitcode, der in dem Abspielzeitcodeanzeigerahmen des LCD-Feldes 5 angezeigt wird, entsprechend der Aktualisierung der Variable play_time erhöht wird. In 59A ist der Abspielzeitcode gleich „00:00:00.000". Bei Beendigung des Abspielens von AOB_FRAME#1 wird die Abspieldauer von 20 msec zu dem Abspielzeitcode addiert, sodass dieser auf „00:00:00.020" aktualisiert wird, was in 59B gezeigt ist. Endet das Abspielen von AOB_FRAME#2, so wird die Abspieldauer von 20 ms zu dem Abspielzeitcode addiert, sodass dieser auf „00:00:00.040" aktualisiert wird, was in 59C gezeigt ist. Auf dieselbe Weise wird, wenn das Abspielen von AOB_FRAME#6 endet, die Abspielzeit von 20 msec zu dem Abspielzeitcode addiert, sodass dieser auf „00:00:00.120"aktualisiert wird, wie in 59D gezeigt ist.
Dies beendet die Beschreibung der AOB-Eingabeprozedur.
In Schritt S31 des Flussdiagramms von 56 wird, wenn der Anwender eine Taste außer der Taste „Play" drückt, die Verarbeitung in diesem Flussdiagramm beendet. Die Verarbeitung, die mit einem Drücken der Tasten „Stopp" oder „Pause" einhergeht, ist bereits beschrieben worden. Wenn der Anwender eine der Tasten drückt, die dafür vorgesehen sind, dass die Abspielvorrichtung eine spezielle Art des Abspielens ausführt, so endet die Verarbeitung in diesem Flussdiagramm oder in den in 56, 57 oder 58 gezeigten Flussdiagrammen, und es wird eine geeignete Verarbeitung für die gedrückte Taste ausgeführt.
Nachfolgend wird die Prozedur beschrieben, die von der CPU 10 ausgeführt wird, (1) wenn eine Vorwärtssuchfunktion in Reaktion darauf, dass der Anwender die Taste „>>" gedrückt hat, ausgeführt wird und (2) wenn die Zeitsuchfunktion in Reaktion darauf, dass der Anwender die Drehscheibe (jog dial) nach Drücken der Taste „Pause" oder „Stop" gedrückt hat, ausgeführt wird.
{52-10_60} Vorwärtssuchfunktion
60 ist ein Flussdiagramm, dass die Prozedur zeigt, die von der CPU 10 ausgeführt wird, wenn die Vorwärtssuchfunktion ausgeführt wird. Drückt der Anwender die Taste „>>", so wird die Bewertung „Ja" in Schritt S31, S42 oder S54 in den Flussdiagrammen von 56, 57 und 58 gegeben, und die CPU 10 führt die Verarbeitung in dem Flussdiagramm von 60 aus.
In Schritt S61 werden die AOB_FRAMEs #x bis #(x + f(t) – 1) in den Entwürfler 7 eingegeben. Hierbei bezeichnen „t" die intermittierende Abspieldauer, f(t) die Anzahl von Frames entsprechend der intermittierenden Abspieldauer und d(t) die Datenmenge entsprechend der intermittierenden Abspieldauer. In Schritt S62 werden die Variable play_time, die die verstrichene Abspielzeit bezeichnet, und die Variable play_data, die die Abspieldatenmenge bezeichnet, jeweils unter Verwendung der intermittierenden Abspieldauer „t", der Anzahl von Frames f(t) entsprechend der intermittierenden Abspieldauer und der Datenmenge d(t) entsprechend der intermittierenden Abspieldauer aktualisiert (x ← x + f(t), play_time ← play_time + t, play_data ← play_data + d(t)). Man beachte, dass die intermittierende Abspieldauer im Allgemeinen bei 240 msec liegt (äquivalent zur Abspieldauer von 12 AOB_FRAMEs).
{52-10_60-1_61A,B}
61A und 61B zeigen den intermittierenden Abspielzeitcode während einer Vorwärtssuchoperation. 61A zeigt den Anfangswert des Abspielzeitcodes, wobei der Abspielpunkt AOB_FRAME#1 in AOB_ELEMENT#51 ist.
Der Abspielzeitcode ist in diesem Fall „00:00:01.000". Werden die AOB_FRAMEs 1 bis 12 in den Entwürfler 7 als intermittierende Abspieldauer eingegeben, so wird die Abspieldauer von 12 AOB_FRAMEs (das heißt 240 msec) zu dem Abspielzeitcode addiert, sodass der Abspielzeitcode zu „00:00:01.240" wird, wie in 61B gezeigt ist.
{52-10_60-2}
Nach dieser Aktualisierung vergleicht die CPU 10 in Schritt S63 die inkrementierte Variable #x mit der Gesamtzahl von Frames in AOB_ELEMENT#y und beurteilt, ob die inkrementierte Variable #x innerhalb der Gesamtzahl von Frames in AOB_ELEMENT#y liegt.
Wie vorstehend erwähnt worden ist, ist die Anzahl von Frames in AOB_ELEMENT mit einer Anordnung am Anfang von AOB gleich „FNs_1st_TMSRTE", die Anzahl von Frames in AOB_ELEMENT mit einer Anordnung in einem mittleren Teil von AOB gleich „FNs_Middle_TMSRTE" und die Anzahl von Frames in AOB_ELEMENT mit einer Anordnung am Ende von AOB gleich „FNs_Last_TMSRTE".
Die CPU 10 nimmt die vorbeschriebene Bewertung durch Vergleichen eines geeigneten Wertes von diesen Werten mit der Variable #x vor. Ist die Variable #x nicht innerhalb des aktuellen AOB_ELEMENT#y, so bewertet die CPU 10 in Schritt S64, ob ein AOB_ELEMENT, das auf AOB_ELEMENT#y folgt, vorhanden ist.
Ist AOB_ELEMENT#y das letzte AOB_ELEMENT in einem AOB_BLOCK, so ist kein AOB_ELEMENT vorhanden, das auf AOB_ELEMENT#y folgt, sodass die Bewertung „nein" in Schritt S64 gegeben wird und die Verarbeitung in dem vorliegenden Flussdiagramm endet. Ist im Umkehrfalle ein AOB_ELEMENT, das auf AOB_ELEMENT#y folgt, vorhanden, so wird in Schritt S65 die Variable #x um die Anzahl von AOB_FRAMEs in AOB_ELEMENT#y verringert, und es wird in Schritt S66 die Variable #y aktualisiert (#y ← #y + 1). Im Ergebnis gibt die Variable #x nunmehr die Frameposition eines Frame im nächsten AOB_ELEMENT#y gemäß Angabe durch die aktualisierte Variable #y an.
Gibt im Umkehrfalle die Variable #x ein AOB_FRAME an, das in dem aktuellen AOB_ELEMENT vorhanden ist (S63: Ja), so wird die Verarbeitung in Schritten S64 bis S66 übersprungen, und die Verarbeitung kehrt zu Schritt S67 zurück.
{52-10_60-3}
Anschließend werden die Variablen #x, play_time und play-data entsprechend der intermittierenden Überspringdauer aktualisiert. Die Dauer „skip_time", die zu der intermittierenden Überspringdauer äquivalent ist, liegt bei 2 s, die Anzahl von Frames, die zu skip_time äquivalent ist, ist als f(skip_time) gegeben und die Datenmenge, die zu skip_time äquivalent ist, ist als d(skip_time) gegeben. In Schritt S67 werden diese Werte zur Aktualisierung der Variablen #x, play_time und play-data (#x ← #x + f(skip_time), play_time ← play_time + skip_time und play_data ← play-data + d(skip_time) verwendet.
{52-10_60-4_61C}
Wie in 61C gezeigt ist, wird die intermittierende Überspringdauer zu der Variable #x addiert, die eine Frameposition innerhalb AOB_ELEMENT#51 zeigt. Überschreitet die aktualisierte Variable #x die Anzahl von Frames in AOB_ELEMENT#51, so wird #y aktualisiert, wodurch das nächste AOB_ELEMENT und die Anzahl von Frames angegeben werden, wobei die Anzahl von Frames in AOB_FRAME#51 von der Variable #x subtrahiert wird. Als Ergebnis gibt die Variable #x nunmehr eine Frameposition innerhalb AOB_ELEMENT#52 gemäß Angabe durch die aktualisierte Variable #y an. Der Wert 2.000 (gleich 2 s) wird anschließend zu dem vorliegenden Wert „00:00:01.240" des Abspielzeitcodes addiert, sodass dieser zu „00:00:03.240" wird. Die Variable #x wird durch Berechnen von (3240 msec – 2000 msec)/20 msec aktualisiert, was den Wert „62" ergibt, und gibt so AOB_FRAME#62 in AOB_ELEMENT#52 an.
{52-10_60-5_61(d)}
Sobald AOB_FRAME#62 in AOB_ELEMENT#52 in den Entwürfler 7 eingegeben wird, wird der Abspielzeitcode, wie in 61D gezeigt ist, durch Addieren von „0.240" zu dem aktuellen Wert von „00:00:03.240" addiert, was „00:00:03.480" ergibt.
In Schritt S67 werden die Variablen entsprechend der intermittierenden Überspringzeit aktualisiert. Anschließend wird die Verarbeitung in Schritten S68 bis S71 ausgeführt. Die Verarbeitung in Schritten S68 bis S71 ist dieselbe wie die Verarbeitung in Schritten S63 bis S66 und aktualisiert damit die Variable #y um die Anzahl von Frames äquivalent zu der intermittierenden Überspringzeit „skip_time", bevor geprüft wird, ob die Variable #x immer noch ein AOB_FRAME innerhalb des aktuellen AOB_ELEMENT#y anzeigt. Ist dem nicht so, so wird die Variable #y aktualisiert, sodass das nächste AOB_ELEMENT als AOB_ELEMENT#y eingestellt wird, und die Variable #x wird derart umgewandelt, dass sie eine Frameposition im nächsten AOB_ELEMENT angibt.
Sobald die Variablen #x und #y in Entsprechung zu der intermittierenden Abspielzeit und der intermittierenden Überspringzeit sind, bezieht sich die CPU 10 in Schritt S72 auf TKTMSRT und berechnet die Startadresse für AOB_ELEMENT#y. Anschließend beginnt in Schritt S73 die CPU 10 mit der Suche nach einem ADTS-Header ausgehend von der Startadresse von AOB-ELEMENT#y, um AOB_FRAME#x zu erfassen. In Schritt S74 bewertet die CPU 10, ob der Anwender eine Taste außer der Vorwärtssuchtaste gedrückt hat. Ist dem nicht so, so werden die AOB_FRAMEs von AOB_FRAME#x bis AOB_FRAME#x+f(t)-1 in den Entwürfler 7 eingegeben, und die Verarbeitung in Schritten S62 bis S73 wird wiederholt.
Die vorliegende Prozedur inkrementiert die Variablen #x und #y, die AOB_FRAME#x beziehungsweise AOB_ELEMENT#y angegeben, und derart rückt die Abspielposition vor. Anschließend wird, wenn der Anwender die Taste „Play" drückt, die Bewertung „Nein" in 74 abgegeben, und die Verarbeitung endet im vorliegenden Flussdiagramm.
{52-11} Ausführen der Zeitsuchfunktion
Nachfolgend wird die Verarbeitung beschrieben, die vorgenommen wird, wenn die Zeitsuchfunktion verwendet wird. Zunächst werden die Spuren beziehungsweise Tracks in der Standardspiellisteninformation angezeigt, und der Anwender gibt eine gewünschte Spur an. Wird die gewünschte Spur angezeigt und hat der Anwender die Drehscheibe bedient, so wird der Abspielzeitcode aktualisiert. Drückt der Anwender anschließend die Taste „Play", so wird der Abspielzeitcode an diesem Punkt verwendet, um einen Wert in der Variable „Jmp_Entry" in Sekunden einzustellen.
Anschließend wird eine Bewertung dahingehend vorgenommen, ob die angezeigte Spur aus einer Vielzahl von AOBs oder einem einzelnen AOB zusammengesetzt ist. Ist die Spur aus einem einzelnen AOB zusammengesetzt, so werden die Variablen #y und #x derart berechnet, dass sie Gleichung 2 genügen. Anschließend wird eine Suche nach AOB_FRAME#x ab der Adresse an der (y + 2)-ten Position in TICTMSRT entsprechend diesem AOB begonnen. Sobald dieser AOB_FRAME#x gefunden ist, beginnt das Abspielen ab AOB_FRAME#x.
{52-12}
Setzt sich die Spur aus einer Vielzahl von AOBs zusammen, so werden die Variablen #n (zur Angabe von AOB), #y und #x derart berechnet, dass sie Gleichung 3 genügen. Anschließend wird eine Suche nach AOB_FRAME#x ab der Adresse in der (y + 2)-ten Position in TKTMSRT entsprechend AOB#n begonnen. Sobald AOB_FRAME#x aufgefunden ist, startet das Abspielen ab AOB_FRAME#x.
Nachstehend wird der Fall beschrieben, in dem das Abspielen ab einer willkürlichen Position mit einem AOB beginnt, wo „FNs_1st_TMSRTE" in BIT gleich "80 Frames", „FNs_Middle_TMSRTE" in BIT gleich „94 Frames" und „FNs_Last_TMSRTE" in BIT „50 Frames" ist.
{52-13_62A,B}
Ein spezifisches Beispiel für die Verwendung der Zeitsuchfunktion wird nachfolgend beschrieben, wobei hier gezeigt wird, wie AOB_ELEMENT und die Frameposition, ab der das Abspielen begonnen werden soll, spezifiziert werden, wenn ein Abspielzeitcode unter Verwendung der Drehscheibe angezeigt wird.
Wie in 62A gezeigt ist, hält der Anwender die Abspielvorrichtung in der Hand und dreht die Drehscheibe mit dem rechten Daumen, um den Abspielzeitcode "00:04:40.000 (280 sec) anzugeben. Ist BIT in TKI für dieses AOB derart, wie in 62B gezeigt ist, so wird Gleichung 2 folgendermaßen verwendet. 280 sec = (FNs_1st_TMSRTE + (FNs_Middle_TSMRTE × y) + x) × 20 msec = (80 + (94 × 148) + 8) × 20 msec
Damit ist Gleichung 2 für die Werte y = 148 und x = 8 erfüllt.
Da y = 148 gilt, erhält man die Eintragsadresse für AOB_ELEMENT#150 (= 148 +2) gemäß Ermittlung aus TKTMSRT. Das Abspielen ab dem angegebenen Abspielzeitcode 00:04:40.000 (= 280.00 sec) kann anschließend durch Beginnen des Abspielens in AOB_FRAME 8 ab dieser Eintragsadresse vorgenommen werden.
{52-14_63_64_65}
Dies beendet die Erläuterung der Verarbeitung der CPU 10 in Reaktion darauf, dass der Anwender die Taste „Play" drückt. Nachfolgend wird das Bearbeitungssteuerprogramm beschrieben, das in dem ROM 4 gespeichert ist. Das Bearbeitungssteuerprogramm wird ausgeführt, wenn der Anwender die Taste „Edit" (Bearbeiten) drückt, und enthält die Prozeduren, die in 63, 64 und 65 gezeigt sind. Nachstehend wird die Verarbeitung in diesem Programm anhand der in diesen Figuren gezeigten Flussdiagramme beschrieben.
{52-14_63-1} Bearbeitungssteuerprogramm
Drückt der Anwender die Taste „Edit", so wird in Schritt S101, siehe 63, ein interaktiver Schirm angezeigt, wo der Anwender gefragt wird, welche der drei grundlegenden Bearbeitungsoperationen „Löschen", „Unterteilen" und „Kombinieren" ausgeführt werden soll. In Schritt S102 beurteilt die CPU 10, welche Operation von dem Anwender in Reaktion auf den interaktiven Schirm gewünscht ist. Beim vorliegenden Beispiel wird davon ausgegangen, dass die Tasten „|<<" und „>>|" in dem Tastenfeld ebenfalls zum Anzeigen der Cursoroperationen „Aufwärts" (up) und „Abwärts" (down) verwendet werden (das heißt, diese Tasten werden als Cursortasten für „Aufwärts" und „Abwärts" verwendet). Gibt der Anwender die Operation „Löschen" an, so geht die Verarbeitung zu der Schleifenprozedur über, die von Schritten S103 und S104 gebildet wird.
In Schritt S103 beurteilt die CPU 10, ob der Anwender die Taste „|<<" oder „>>|" gedrückt hat. In Schritt S104 beurteilt die CPU 10, ob der Anwender die Taste „Edit" gedrückt hat. Hat der Anwender die Taste „|<<" oder „>>|" gedrückt, so geht die Bearbeitung von Schritt S103 zu Schritt S105 über, wo die angegebene Spur als Spur eingestellt wird, die zu bearbeiten ist. Hat der Anwender demgegenüber die Taste „Edit" gedrückt, so wird die angegebene Spur als diejenige Spur eingestellt, die zu löschen ist. Die in 44 gezeigte Verarbeitung wird ausgeführt, sodass TKI_BLK_ATR jeder TKI für die angegebene Spur auf „nicht verwendet" eingestellt wird, um die angegebene Spur zu löschen.
{52-14_63-2} Prozess des Kombinierens
Wählt der Anwender den Prozess des Kombinierens aus, so geht die Verarbeitung von Schritt S102 zu der Schleifenprozedur über, die von Schritten S107 bis S109 gebildet wird. In der von Schritten S107 bis S109 gebildeten Schleifenprozedur empfängt die Abspielvorrichtung Anwendereingaben über die Tasten „|<<", „>>|" und „Edit". Drückt der Anwender die Tasten „|<<" oder „>>|", so geht die Verarbeitung von Schritt S107 zu Schritt S111 über, wobei die angegebene Spur auf der Anzeige markiert wird. Drückt der Anwender die Taste „Edit", so wird in Schritt S108 die Bewertung „Ja" gegeben, und die Verarbeitung geht zu Schritt S111 über. In Schritt S111 wird die aktuelle angegebene Spur als erste Spur eingestellt, die bei diesem Verarbeitungsprozess verwendet werden soll, und der Prozess kehrt zu der Schleifenprozedur zurück, die von Schritten S107 bis S109 gebildet wird.
Ist die zweite Spur zum Bearbeiten ausgewählt, so wird in Schritt S109 die Bewertung „Ja" gegeben, und die Verarbeitung geht zu Schritt S112 über. In Schritt S112 bezieht sich die CPU 110 auf die BITs in TKIs der ersteren und letzteren Spuren und beurteilt, welcher Typ von AOBs (Typ 1 oder Typ 2) an dem jeweiligen Anfang und Ende jeder dieser Spuren und der Spuren zu beiden Seiten der Spur, falls vorhanden, gegeben ist.
Nach Identifizieren des Typs von jedem relevanten AOB beurteilt die CPU 10 in Schritt S113, ob die Anordnung von AOBs einem bestimmten Muster entspricht. Entspricht die Anordnung von AOBs einem der vier Mustern gemäß 32A bis 32D, wobei deutlich ist, dass die drei AOBs vom Typ 2 nach dem Kombinieren nicht aufeinanderfolgend vorliegen, werden die ersteren und letzteren Spuren in Schritt S115 zu einer einzigen Spur kombiniert.
Mit anderen Worten, die in 46 gezeigte Operation wird für TKI und TKI_BLK_SRP entsprechend diesen AOBs ausgeführt. Durch Neuschreiben von TKI_BLK_ATRs in TKIs wird die Vielzahl von Spuren, die zum Bearbeiten ausgewählt sind, zu einer einzigen Spur kombiniert. Entspricht die Anordnung von AOBs keinem der Muster von 32A bis 32D, was bedeutet, dass drei oder mehr AOBs vom Typ 2 nach dem Kombinieren vorhanden sind, so stellt die CPU 10 fest, dass die kombinierte Spur einen Pufferunterlauf (buffer underflow) verursachen kann und beendet den Prozess des Kombinierens.
{52-14_64-1} Prozess des Unterteilens von Spuren
Gibt der Anwender an, dass eine Spur unterteilt werden soll, so geht die Verarbeitung von Schritt S102 zu der Schleifenverarbeitung über, die von Schritten S116 bis S117 gebildet wird. In der Schleifenprozedur, die von Schritten S116 bis S117 gebildet wird, empfängt die Abspielvorrichtung Anwendereingaben über die Tasten „|<<", „>>|" und „Edit".
Drückt der Anwender die Taste „|<<" oder „>>|", so geht die Verarbeitung von Schritt S116 zu Schritt S118 über, wo die angegebene Spur als diejenige Spur eingestellt wird, die bearbeitet werden soll. Drückt der Anwender die Taste „Edit", so wird die Bewertung „Ja" in Schritt S117 gegeben, und die Verarbeitung geht zu Schritt S119 über.
In Schritt S119 wird die angegebene Spur als diejenige Spur bestimmt, die bearbeitet werden soll, und die Verarbeitung geht zu Schritt S120 über, wo das Abspielen dieser Spur beginnt. In Schritt S121 empfängt die Abspielvorrichtung eine Anwendereingabe über die Taste „Mark" (Markieren).
Drückt der Anwender die Taste „Mark", so wird das Abspielen der Spur angehalten, und die Verarbeitung geht zu der Schleifenprozedur über, die von Schritten S122 und S123 gebildet wird. In Schritt S122 empfängt die Abspielvorrichtung Anwenderoperationen, die über die Drehscheibe eingegeben wurden. Dreht der Anwender die Drehschreibe, so wird der Abspielzeitcode in Schritt S124 entsprechend der Drehung der Drehscheibe aktualisiert.
Anschließend wird die Schleifenprozedur, die von Schritten S122 und 123 gebildet wird, wiederholt. Drückt der Anwender die Taste „Edit", so geht die Verarbeitung von Schritt S123 zu Schritt S125 über, wo der Abspielzeitcode, der angezeigt wird, wenn der Anwender die Taste „Edit" gedrückt hat, als Unterteilungsgrenze eingestellt wird. Man beachte, dass eine Undo-Funktion (Rückgängigmachen) für diese Einstellung der Untertei lungsgrenze gegeben sein kann, um den Anwender in die Lage zu versetzen, die ausgewählte Unterteilungsgrenze rückgängig zu machen.
Anschließend wird die im Zusammenhang mit 47 erläuterte Verarbeitung in Schritt S126 ausgeführt, um DPLI und TKI derart zu aktualisieren, dass die ausgewählte spur unterteilt wird.
{52-14_65-1} Prozess des Einstellens einer Spielliste
Wählt der Anwender das Einstellen einer Spielliste, so schaltet die Verarbeitung zu der Prozedur hinüber, die in dem Flussdiagramm von 65 gezeigt ist. Gemäß diesem Flussdiagramm wird die in diesem Flussdiagramm angegebene Variable k verwendet, um die Position einer Spur in der Abspielreihenfolge gemäß Angabe durch die Spielliste, die bearbeitet wird, anzugeben. Das Flussdiagramm von 65 beginnt mit der Variable k, die in Schritt S131 auf „1" initialisiert wird, bevor die Verarbeitung zu der Schleifenverarbeitung übergeht, die von Schritten S132 bis S134 gebildet wird.
In der Schleifenprozedur, die von Schritten S132 bis S134 gebildet wird, empfängt die Abspielvorrichtung Anwenderoperationen, die über die Tasten „|<<", „>>|", „Edit" und „Stopp" eingegeben worden sind. Drückt der Anwender die Tasten „|<<" oder „>>|", so geht die Verarbeitung von Schritt S132 zu Schritt S135 über, wo eine neue Spur entsprechend der gedrückten Taste „|<<" oder „>>|" angegeben wird. Drückt der Anwender die Taste „Edit", so wird in Schritt S133 die Bewertung „Ja" gegeben, und die Verarbeitung geht zu Schritt S136 über.
In Schritt S136 wird die Spur, die angegeben wird, wenn der Anwender die Taste „Edit" drückt, als k-te Spur in der Abspielreihenfolge ausgewählt. Anschließend wird in Schritt S137 die Variable k inkrementiert, und die Verarbeitung geht zu der Schleifenprozedur über, die von S132 bis S134 gebildet wird. Diese Prozedur wird wiederholt, sodass die zweite, dritte und vierte Spur aufeinanderfolgend ausgewählt werden. Drückt der Anwender die Taste „Stopp" zur Spezifizierung bestimmter Spuren, die in der spezifizierten Reihenfolge als neue Spielliste abgespielt werden sollen, so geht die Verarbeitung von Schritt S134 zu Schritt S138 über, wo eine PLI erzeugt wird, die von PL_TK_SRPs gebildet wird, die die TKIs entsprechend diesen Spuren spezifizieren.
{66-1} Verarbeitungsvorrichtungen
Nachfolgend wird ein Beispiel für eine Verarbeitungsvorrichtung für die Flashspeicherkarte 31 beschrieben. 66 zeigt ein Beispiel für eine Abspielvorrichtung. Die Abspielvorrichtung kann mit dem Internet verbunden sein und ist ein Standardpersonalcomputer, der einen Empfang vornehmen kann, wenn ein verschlüsseltes SD-Audioverzeichnis über Kommunikationsleitungen durch einen elektronischen Musikverteilungsdienst an die Verarbeitungsvorrichtung gesendet wird oder wenn ein Audiodatentransportstream über Kommunikationsleitungen durch den elektronischen Musikverteilungsdienst an die Aufzeichnungsvorrichtung gesendet wird.
{67-1} Hardwarezusammensetzung der Abspielvorrichtung
67 zeigt die Hardwarezusammensetzung der vorliegenden Abspielvorrichtung.
Wie in 67 gezeigt ist, umfasst die Abspielvorrichtung einen Kartenanschluss 21 zum Anschließen der Aufzeichnungsvorrichtung an die Flashspeicherkarte 31, einen RAM 22, eine nicht herausnehmbare Plattenvorrichtung 23 zum Speichern und Aufzeichnen eines Steuerprogramms, das die Gesamtsteuerung der Aufzeichnungsvorrichtung vornimmt, einen A/D-Wandler 24, der eine A/D-Wandlung an den über ein Mikrofon eingegebenen Audiodaten zur Erzeugung von PCM-Daten vornimmt, einen ACC-Codierer 25 zum Codieren der PCM-Daten in Einheiten einer festen Zeit und Zuweisen von ADTS-Headern zur Erzeugung von AOB_FRAMEs, eine Verwürfelungseinheit 26 zum Verschlüsseln der AOB_FRAMEs unter Verwendung eines anderen FileKey für jeden AOB_BLOCK, eine Modemvorrichtung 27 zum Empfangen eines Audiodatentransportstreams, wenn ein verschlüsseltes SD-Audioverzeichnis über Kommunikationsleitungen durch einen elektronischen Musikverteilungsdienst an die Aufzeichnungsvorrichtung gesendet wird oder wenn ein Audiodatentransportstream über Kommunikationsleitungen durch einen elektronischen Musikverteilungsdienst an die Aufzeichnungsvorrichtung gesendet wird, eine CPU 28 zum Vornehmen einer Gesamtsteuerung der Aufzeichnungsvorrichtung, eine Tastatur 29 zum Empfangen von Eingaben von dem Anwender und eine Anzeige 30.
{67-2} Eingabeschaltungen RT1 bis RT4
Wird ein verschlüsseltes SD-Audioverzeichnis, das in den Datenbereich und den Authentisierungsbereich geschrieben werden soll, über Kommunikationsleitungen durch einen elektronischen Musikverteilungsdienst an die Aufzeichnungsvorrichtung gesendet, so kann die Aufzeichnungsvorrichtung das verschlüsselte SD-Audioverzeichnis in den Datenbereich und den Authentisierungsbereich der Flashspeicherkarte 31 schreiben, sobald das verschlüsselte SD-Audioverzeichnis richtig empfangen worden ist.
(1) Wird demgegenüber ein Audiodatentransportstream, der nicht die Form des SD-Audioverzeichnisses hat, durch einen elektronischen Musikverteilungsdienst an die Aufzeichnungsvorrichtung gesendet (2) oder werden Daten im PCM-Format in die Aufzeichnungsvorrichtung eingegeben oder (3) wird ein analoger Audioton von der Aufzeichnungsvorrichtung aufgezeichnet, so bedient sich die Aufzeichnungsvorrichtung der nachfolgenden vier Eingaberouten (routes) zum Schreiben des Audiodatentransportstreams auf die Flashspeicherkarte 31.
Wie in 67 gezeigt ist, werden die vier Eingaberouten RT1, RT2, RT3 und RT4 zur Eingabe eines Audiodatentransportstreams verwendet, wenn ein Audiodatentransportstream auf der Flashspeicherkarte 31 gespeichert wird.
{67-3} Eingaberoute RT1
Die Eingaberoute RT1 wird verwendet, wenn ein verschlüsseltes SD-Audioverzeichnis über Kommunikationsleitungen durch den elektronischen Musikverteilungsdienst an die Aufzeichnungsvorrichtung gesendet wird oder wenn ein Audiodatentransportstream über Kommunikationsleitungen durch einen elektronischen Musikverteilungsdienst an die Aufzeichnungsvorrichtung gesendet wird. In diesem Fall werden die AOB_FRAMEs, die in dem Transportstream enthalten sind, derart verschlüsselt, dass ein anderer FileKey für die AOB_FRAMEs in verschiedenen AOBs verwendet wird. Da keine Notwendigkeit der Verschlüsselung oder Codierung eines verschlüsselten Transportstreams besteht, können das SD-Audioverzeichnis oder der Audiodatentransportstream direkt auf dem RAM 22 im verschlüsselten Zustand gespeichert werden.
{67-4} Eingaberoute RT2
Die Eingaberoute RT2 wird verwendet, wenn Audioton über ein Mikrofon eingegeben wird. In diesem Fall wird der über das Mikrofon eingegebene Audioton einer A/D-Umwandlung durch den A/D-Umwandler 24 unterzogen, um PCM-Daten zu erzeugen. Die PCM-Daten werden anschließend von dem AAC-Codierer 25 codiert, und es werden ihnen ADTS-Header zugewiesen, um AOB_FRAMEs zu erzeugen. Anschließend verschlüsselt die Verschlüsselungseinheit 26 die AOB_FRAMEs unter Verwendung eines anderen FileKey für sämtliche AOB_FRAMEs in verschiedenen AOB_FILEs zur Erzeugung verschlüsselter Audiodaten. Schließelich werden die verschlüsselten Audiodaten in dem RAM 22 gespeichert.
{67-5} Eingaberoute RT3
Die Eingaberoute RT3 wird verwendet, wenn von einer CD gelesene PCM-Daten in die Aufzeichnungsvorrichtung eingegeben werden. Da die Daten im PCM-Format eingegeben werden, können die Daten in ihrer vorliegenden Form in den AAC-Codierer 25 eingegeben werden. Die PCM-Daten werden von dem AAC-Codierer 25 codiert und mit ADTS-Headern versehen, um AOB_FRAMEs zu erzeugen.
Anschließend verschlüsselt die Verwürfelungseinheit 26 die AOB_FRAMEs unter Verwendung eines anderen FileKey für die AOB_FRAMEs in verschiedenen AOBs, um verschlüsselte Audiodaten zu erzeugen. Schließlich werden die verschlüsselten Audiodaten in dem RAM 22 gespeichert.
{67-6} Eingaberoute RT4
Die Eingaberoute RT4 wird verwendet, wenn ein über eine der drei Eingaberouten RT1, RT2 und RT3 eingegebener Transportstream auf die Flashspeicherkarte 31 geschrieben wird.
Dieses Speichern von Audiodaten geht mit der Erzeugung von TKIs und Standardspiellisteninformation einher. Auf dieselbe Weise wie bei der Abspielvorrichtung wird die Hauptfunktion der Aufzeichnungsvorrichtung in dem ROM gespeichert. Dies bedeutet, dass ein Aufzeichnungsprogramm, das die charakteristische Verarbeitung der Aufzeichnungsvorrichtung, das heißt das Aufzeichnen von AOBs, den Spurverwalter und den Spiellistenverwalter, enthält, in der nicht herausnehmbaren Plattenvorrichtung 23 gespeichert ist.
{67-7_68} Verarbeiten der Aufzeichnungsvorrichtung
Nachfolgend wird die Verarbeitung bei der Aufzeichnungsprozedur, die einen Transportstream auf die Flashspeicherkarte 31 über die Eingaberouten RT1, RT2, RT3 und RT4 schreibt, unter Bezugnahme auf das Flussdiagramm von 68, das diese Verarbeitung zeigt, beschrieben.
Die Variablen „Frame_Number" und „Data_Size", die in diesem Flussdiagramm verwendet werden, sind folgendermaßen definiert. Die Variable Frame_Number wird zur Verwaltung der Gesamtzahl der AOB_FRAMEs verwendet, die bereits in AOB_FILE aufgezeichnet worden sind. Die Variable Data_Size wird verwendet, um die Datengröße der AOB_FRAMEs zu verwalten, die bereits in AOB_FILE aufgezeichnet worden sind.
Die Verarbeitung in diesem Flussdiagramm beginnt in Schritt S200 damit, dass die CPU 28 die Standardspielliste und den Spurverwalter erzeugt. In Schritt S201 initialisiert die CPU 28 die Variable #z (z ← 1). In Schritt S202 erzeugt die CPU 28 AOB_FILE#z und speichert dies in dem Datenbereich der Flashspeicherkarte 31. An diesem Punkt werden der Dateiname, die Dateinamenerweiterung und eine erste Clusternummer für AOB_FILE#z in einem Verzeichniseintrag in dem SD-Audioverzeichnis in dem Datenbereich eingestellt. Anschließend erzeugt die CPU 28 in Schritt S203 TKI#z und speichert diesen Wert in dem Spurverwalter. In Schritt S204 erzeugt die CPU 28 DPL_TK_SRP#w und speichert diesen Wert in der Standardspiellisteninformation. Anschließend initialisiert in Schritt S205 die CPU 28 die Variable #y (y ← 1). In Schritt S206 initialisiert die CPU 28 Frame_Numer und Data_Size (Frame_Number ← 0, Data_Size ← 0).
In Schritt S207 stellt die CPU 28 fest, ob die Eingabe des Audiodatentransportstreams, der in AOB_FILE# geschrieben werden soll, beendet ist. Wird die Eingabe des Audiodatentransportstreams, der von dem AAC-Codierer 25 codiert und von der Verwürfelungseinheit 26 verschlüsselt worden ist, in den RAM 22 fortgesetzt und ist eine Fortsetzung des Schreibens von Clusterdaten notwendig, so gibt die CPU 28 die Bewertung „Nein" in Schritt 207 aus, und die Verarbeitung geht zu Schritt S209 über.
In Schritt S209 stellt die CPU fest, ob die Menge der AAC-Audiodaten, die sich in dem RAM 22 angesammelt haben, wenigstens gleich der Clustergröße ist. Ist dem so, so gibt die CPU 28 die Bewertung „Ja" aus, und die Verarbeitung geht zu Schritt S210 über, wo eine der Clustergröße gleich Menge von AAC-Audiodaten auf die Flashspeicherkarte 31 geschrieben wird. Die Verarbeitung geht dann zu Schritt S211 über.
Haben sich nicht genügend AAC-Audiodaten in dem RAM 22 angesammelt, so wird Schritt S210 übersprungen, und die Verarbeitung geht zu Schritt S211 über. In Schritt S211 inkrementiert die CPU Frame_Number (Frame_Number ← Frame_Number + 1) und erhöht den Wert der Variablen Data_Size um die Datengröße von AOB_FRAME.
Nach dieser Aktualisierung beurteilt die CPU 28 in Schritt S212, ob der Wert von Frame Number die Anzahl von Frames erreicht hat, die in „FNs_Middle_TMSRTE" eingestellt ist, und der Wert von „FNs_Middle_TMSRTE" wird entsprechend der Abtastfrequenz eingestellt, die beim Codieren des Audiodatentransportstreams verwendet wird. Hat der Wert von Frame_Number die Anzahl von Frames erreicht, die in „FNs_Middle_TMSRTE" eingestellt ist, so gibt die CPU 28 die Bewertung „Ja" in Schritt S212 aus. Ist dem nicht so, so gibt die CPU 28 die Bewertung „Nein" aus, und die Verarbeitung kehrt zu Schritt S207 zurück. Die Verarbeitung in Schritten S207 bis S112 wird wiederholt, bis entweder in Schritt S207 oder in Schritt S212 die Bewertung „Ja" gegeben wird.
Erreicht die Variable Frame_Number den Wert „FNs_Middle_TMSRTE", so gibt die CPU 28 die Bewertung „Ja" in Schritt S212 aus, und die Verarbeitung geht von Schritt S212 zu Schritt S213 über, wo Data_Size (Datengröße) in TKTMSRT von TKI#z als TMSRT_entry#y für AOB_ELEMENT#y gespeichert wird. In Schritt S214 inkrementiert die CPU 28 die Variable #y (#y ← #y + 1), bevor in Schritt S215 geprüft wird, ob die Variable #y „252" erreicht hat.
Der Wert „252" wird verwendet, da es sich hierbei um die Maximalzahl von AOB_ELEMENTs handelt, die in einem einzelnen AOB gespeichert werden können. Ist die Variable #y unterhalb von 252, so geht die Verarbeitung zu Schritt S216 über, wo die CPU 28 bewertet, ob eine Stillphase (silence) vorbestimmter Länge in dem codierten Audioton enthalten ist, was bedeutet, dass die Audiodaten eine Lücke erreicht haben, die zwischen Spuren vorhanden ist. Ist keine fortwährende Stillphase vorhanden, so wird die von Schritten S206 bis S215 gebildete Verarbeitung wiederholt. Hat die Variable #y den Wert 252 erreicht, oder ist eine Stillphase vorbestimmter Länge in dem codierten Audioton vorhanden, so wird die Bewertung „Ja" in einem der Schritte S215 und S216 gegeben, und die Verarbeitung geht zu Schritt S217 über, wo die Variable #z inkrementiert wird (#z ← #z + 1).
Anschließend wird die Verarbeitung in Schritten S202 bis S216 für die inkrementierte Variable #z wiederholt. Durch Wiederholen dieser Verarbeitung kann die CPU 28 AOBs mit einer Vielzahl von AOB_ELEMENTs in einer nacheinander gegebenen Aufzeichnung auf der Flashspeicherkarte 31 aufweisen.
Ist die Übertragung eines Audiodatentransportstreams durch den AAC-Codierer 25, die Verwürfelungseinheit 26 und die Modemvorrichtung 27 vollständig, was bedeutet, dass die Eingabe des Audiodatentransportstreams, der in AOB_FILE#z zu schreiben ist, vollständig ist, so wird in Schritt S207 die Bewertung „Ja" ausgegeben, und die Vorrichtung geht zu Schritt S208 über. In Schritt S208 speichert die CPU 28 den Wert der Variablen Data_Size in TKTMSRT von TKI#z als TMSRT_Entry#y für AOB_ELEMENT#y. Nach dem Speichern der in dem RAM 22 angesammelten Audiodaten in der AOB-Datei entsprechend AOB#z endet die Verarbeitung in diesem Flussdiagramm.
Die vorbeschriebene Verarbeitung liefert einen verschlüsselten Audiodatentransportstream, der auf der Flashspeicherkarte 31 gespeichert wird. Die nachfolgende Prozedur wird anschließend verwendet, um den für die Verschlüsselung dieses verschlüsselten Audiodatentransportstreams erforderlichen FileKey in dem Authentisierungsbereich zu speichern.
Ist der Audiodatentransportstream über die Eingaberoute RT1 eingegeben worden, so werden die AOB-Datei beziehungsweise die AOB-Dateien, die TKMG speichernde Datei, die PLMG speichernde Datei und die Verschlüsselungsschlüsselspeicherdatei, die einen anderen FileKey für jedes AOB speichert, durch den Bereitsteller eines elektronischen Musikverteilungsdienstes an die Aufzeichnungsvorrichtung übersandt. Die CPU 28 empfängt diese Dateien und schreibt die AOB-Datei beziehungsweise die AOB-Dateien, die TKMG speichernde Datei und die PLMG speichernde Datei in den Anwenderbereich der Flashspeicherkarte 31. Demgegenüber schreibt die CPU 28 nur die Verschlüsselungsschlüsselspeicherdatei, die einen anderen FileKey für jedes AOB speichert, in den Authentisierungsbereich.
Wird der Audioton über die Eingaberouten RT2 oder RT3 eingegeben, so erzeugt die CPU 28 jedes Mal einen anderen FileKey, wenn die Codierung eines neuen AOB beginnt und stellt den erzeugten Schlüssel in der Verwürfelungseinheit 26 ein. Zusätzlich zur Verwendung seitens der Verwürfelungseinheit 26 zum Zwecke der Verschlüsselung des aktuellen AOB wird dieser FileKey im Gefolge des FileKey-Eintrages in der Ver schlüsselungsschlüsselspeicherdatei gespeichert, die sich in dem Authentisierungsbereich befindet.
Eingedenk des vorbeschriebenen Ausführungsbeispieles werden die die AOBs speichernden Dateien unter Verwendung verschiedener Verschlüsselungsschlüssel verschlüsselt, sodass für den Fall, dass Verschlüsselungsschlüssel, die zur Verschlüsselung einer Datei verwendet werden, decodiert werden und offenliegen, der offenliegende Verschlüsselungsschlüssel nur zur Entschlüsselung einer Datei verwendet werden kann, die ein AOB speichert, weshalb ein derartiges Offenliegen keinerlei Auswirkungen auf andere AOBs hat, die in anderen Dateien gespeichert sind. Dies minimiert den Schaden, der verursacht wird, wenn ein Verschlüsselungsschlüssel offen liegt.
Man beachte, dass ungeachtet dessen, dass die vorhergehende Beschreibung auf ein Beispielssystem abstellt, von dem man glaubt, das es die effektivste Ausführung der vorliegenden Erfindung ist, die Erfindung nicht auf dieses System beschränkt ist. Es sind verschiedenartige Abwandlungen innerhalb des Schutzbereiches der Erfindung möglich, wobei Beispiele hierfür nachfolgend als (a) bis (e) angegeben sind.

(a) Das vorbeschriebene Ausführungsbeispiel nennt einen Halbleiterspeicher (Flashspeicherkarte) als verwendetes Aufzeichnungsmedium, obwohl bei der vorliegenden Erfindung auch andere Medien zum Einsatz kommen können, darunter optische Platten, so beispielsweise eine DVD-RAM oder eine Festplatte.
(b) Beim vorbeschriebenen Ausführungsbeispiel wurden die Audiodaten als im AAC-Format vorliegend beschrieben. Bei der vorliegenden Erfindung können die Audiodaten jedoch auch in einem beliebigen anderen Format vorliegen, so beispielsweise in MP3 (MPEG1 AudioLayer 3), Dolby-AC3 oder DTS (Digital Theater System).
(c) Die TKMG speichernde Datei und die PLMG speichernde Datei wurden als von dem Bereitsteller des elektronischen Musikverteilungsdienstes in vollständiger Form empfangen beschrieben. Die Hauptinformation, die zum Erzeugen von TKMG und PLMG verwendet wird, kann jedoch auch zusammen mit der Verschlüsselungsschlüsselspeicherdatei übermittelt werden, die einen anderen Verschlüsselungsschlüssel für jedes AOB speichert. Die Aufzeichnungsvorrichtung kann diese Information anschließend zur Ermittlung von TKMG und PLMG verarbeiten, die sie anschließend auf der Flashspeicherkarte aufzeichnet.
(d) Zur Erleichterung der Erläuterungen wurden die Aufzeichnungsvorrichtung und die Abspielvorrichtung als separate Vorrichtungen dargestellt, obwohl auch tragbare Abspielvorrichtungen mit der Funktionspalette einer Aufzeichnungsvorrichtung versehen sein können und auch eine Aufzeichnungsvorrichtung in Form eines Personalcomputers mit der Funktionspalette einer Abspielvorrichtung versehen sein kann. Abgesehen von der tragbaren Abspielvorrichtung und der PC-Aufzeichnungsvorrichtung kann die Funktionspalette der Abspielvorrichtung und der Aufzeichnungsvorrichtung auch bei einer Kommunikationsvorrichtung bereitgestellt werden, die in der Lage ist, Inhalte aus einem Netzwerke herunterzuladen.
Bei einem Beispiel kann ein Mobiltelefon, das auf das Internet zugreifen kann, mit Funktionen der Abspielvorrichtung und der Aufzeichnungsvorrichtung gemäß Beschreibung beim vorliegenden Ausführungsbeispiel versehen sein. Das Mobiltelefon kann über ein drahtloses Netzwerk heruntergeladene Inhalte auf der Flashspeicherkarte 31 auf dieselbe Weise wie beim vorbeschriebenen Ausführungsbeispiel speichern. Während die beim vorliegenden Ausführungsbeispiel beschriebene Aufzeichnungsvorrichtung mit der Modemvorrichtung 27 zur Herstellung einer Verbindung mit dem Internet ausgestattet ist, kann anstatt dessen auch eine andere Vorrichtung verwendet werden, die einen Anschluss zum Internet herstellen kann, so beispielsweise ein Endgerät für eine ISDN-Leitung.
(e) Die in den Flussdiagrammen von 55 bis 58, 60, 63 bis 65 und 68 gezeigten Prozeduren können von ausführbaren Programmen ausgeführt weiden, die auf einem Aufzeichnungsmedium aufgezeichnet werden, das anschließend verteilt und verkauft wird. Dieses Aufzeichnungsmedium kann eine IC-Karte, eine optische Platte, eine Diskette oder dergleichen sein, wobei die auf dem Aufzeichnungsmedium aufgezeichneten Programme zunächst in der Standardcomputerhardware installiert werden müssen. Durch Ausführen einer Verarbeitung entsprechend diesen installierten Programmen kann die Standardcomputerhardware dieselbe Funktionspalette wie die Abspielvorrichtung und die Aufzeichnungsvorrichtung gemäß Beschreibung beim vorliegenden Ausführungsbeispiel durchführen.
(f) Während das vorbeschriebene Ausführungsbeispiel denjenigen Fall beschreibt, in dem eine Vielzahl von AOBs und eine Vielzahl von FileKeys auf der Flashspeicherkarte 31 gespeichert sind, müssen eigentlich nur ein AOB und ein FileKey gespeichert werden.

Darüber hinaus ist es für die zu verschlüsselnden AOBs nicht wesentlich, dass die AOBs auf der Flashspeicherkarte 31 im ACC-Format gespeichert sein können.
Zweites Ausführungsbeispiel
Das erste Ausführungsbeispiel befasst sich lediglich mit den verschiedenen Speicherbereichen auf der Flashspeicherkarte 31 und stellt nicht auf die Zusammensetzung der internen Hardware ab. Das zweite Ausführungsbeispiel befasst sich detailliert mit der Zusammensetzung der Hardware der Flashspeicherkarte 31.
{69-1} Zusammensetzung der Hardware der Flashspeicherkarte 31
69 zeigt die Zusammensetzung der Hardware der Flashspeicherkarte 31. Wie in 69 gezeigt ist, umfasst die Flashspeicherkarte 31 drei IC-Chips, nämlich den Steuer-IC 302 den Flashspeicher 303 und den ROM 304.
Der ROM 304 enthält den Spezialbereich gemäß Beschreibung beim ersten Ausführungsbeispiel und wird zur Speicherung der Medienkennung (ID), die auch beim ersten Ausführungsbeispiel erwähnt worden ist, zusätzlich zu einer sicheren Medienkennung (ID) 343, die durch Verschlüsselung der sicheren Medienkennung erzeugt wird, verwendet.
Der Steuer-IC 302 ist eine Steuerschaltung, die sich aus Aktivelementen (logische Gatter) zusammensetzt, und enthält eine Autorisierungseinheit 321, eine Befehlsdecodiereinheit 322, eine Masterkeyspeichereinheit 323, eine Spezialbereichszugriffssteuereinheit 324, eine Authentisierungsbereichszugriffssteuereinheit 325, eine Nichtauthentisierungsbereichszugriffssteuereinheit 326 und eine Verschlüsselungs-/Entschlüsselungsschaltung 327.
Die Autorisierungseinheit 321 ist eine Schaltung, die eine wechselseitige Authentisierung im Challenge-Response-Format mit einer Vorrichtung ausführt, die einen Zugriff auf die Flashspeicherkarte 31 versucht. Die Autorisierungseinheit 321 enthält einen Zufallszahlengenerator, einen Verschlüssler und dergleichen und verifiziert, dass diejenige Vorrichtung, die einen Zugriff auf die Flashspeicherkarte 31 versucht, authentisch ist, indem sie erfasst, ob die Vorrichtung denselben Verschlüssler wie die Autorisierungseinheit 321 aufweist.
Hierbei bezeichnet der Begriff „wechselseitige Authentisierung im Challenge-Response-Format" die Tatsache, dass eine erste Vorrichtung Challenge-Daten an eine zweite Vorrichtung sendet, um die Authentizität der anderen Vorrichtung zu prüfen. Die andere Vorrichtung verarbeitet diese Challenge-Daten auf vorbestimmte Weise, um so deren Authentizität nachzuweisen, und sendet die resultierenden Daten an die erste Vorrichtung als Response-Daten zurück. Die erste Vorrichtung vergleicht die Challenge-Daten mit den Response-Daten, um zu beurteilen, ob die andere Vorrichtung authentisch ist. Da es sich hierbei um eine wechselseitige Authentisierung handelt, wird der Vorgang anschließend wiederholt, wobei die Vorrichtungen ihre Rollen tauschen.
Die Befehlsdecodiereinheit 322 ist eine Steuerung, die eine Decodierschaltung, eine Steuerschaltung und dergleichen aufweist, die einen Befehl (eine Anweisung für die Flashspeicherkarte 31) interpretieren und ausführen, die über den Befehlspin (COM-MAND pin) eingegeben worden ist. Die Befehlsdecodiereinheit 322 steuert die Komponenten 321 bis 327 in dem Steuer-IC 302 entsprechend der Art des eingegebenen Befehls.
Die an die Flashspeicherkarte 31 ausgegebenen Befehle umfassen Befehle, die Daten in dem Flashspeicher 31 lesen, schreiben oder löschen. Beispielsweise greifen im Zusammenhang mit dem Lesen und Schreiben von Daten die Befehle „SecureRead address count" und „SecureWrite address count" auf den Authentisierungbereich zu, während die Befehle „Read address count" und „Write address count" auf den Nichtauthentisierungsbereich zugreifen. Bei diesen Befehlen ist die „Adresse" die Nummer des ersten Sektors, auf den in dem Gebiet zugegriffen wird, das gelesen (oder beschreiben) werden soll, während „count" die Gesamtzahl von Sektoren ist, die gelesen (oder beschrieben) werden sollen. In diesem Fall ist ein Sektor die Einheit, die zum Lesen und Schreiben von Daten in der Flashspeicherkarte 31 verwendet wird und die beim vorliegenden Beispiel 512 Byte ist.
Die Masterkeyspeichereinheit 323 speichert den Masterkey 323a vorab in verschlüsselter Form. Der Masterkey ist der Verschlüsselungsschlüssel, der zur Verschlüsselung der Medienkennung verwendet wird. Ist die Flashspeicherkarte 31 mit einer Vorrichtung verbunden, so wird der Masterkey 323a über die Vorrichtung in verschlüsselter Form weitergereicht. Der Masterkey 323a wird auf eine Weise verschlüsselt, die eine Entschlüsse lung nur durch eine Vorrichtung zulässt, die den Masterkey unter Verwendung spezieller Schlüsselinformation (die im allgemeinen "Vorrichtungskey" genannt wird) empfängt.
Die Spezialbereichszugriffssteuereinheit 324 ist eine Schaltung, die die Mediendaten liest, die in dem ROM 304 gespeichert sind, der den Spezialbereich zur Verfügung stellt. Die Medienkennung, die von der Spezialbereichszugriffssteuereinheit 324 gelesen wird, wird an eine Vorrichtung weitergereicht, die mit der Flashspeicherkarte 31 verbunden ist, woraufhin das Verschlüsseln der Medienkennung unter Verwendung des Masterkey erfolgt, den man durch Entschlüsseln des verschlüsselten Masterkey unter Verwendung des Vorrichtungskey ermittelt.
Die Authentisierungsbereichszugriffssteuereinheit 325 und die Nichtauthentisierungsbereichszugriffssteuereinheit 326 sind Schaltungen, die ein Lesen von Daten aus dem Authentisierungsbereich und dem Nichtauthentisierungsbereich und ein Schreiben von Daten in den Authentisierungsbereich und den Nichtauthentisierungsbereich in dem Flashspeicher 303 vornehmen. Die Authentisierungsbereichszugriffssteuereinheit 325 und die Nichtauthentisierungsbereichszugriffssteuereinheit 326 übertragen Daten an eine externe Vorrichtung beziehungsweise von dieser (so beispielsweise die Aufzeichnungsvorrichtung und die Abspielvorrichtung gemäß Beschreibung im Zusammenhang mit dem ersten Ausführungsbeispiel).
Man beachte, dass diese Zugriffssteuereinheiten 325 und 326 jeweils einen internen Puffer aufweisen, der einen Datenblock speichern und eine Eingabe oder Ausgabe über die mit DATA1 bis DATA4 markierten Pins vornehmen kann. Mit Blick auf die Logik werden derartige Eingabe- und Ausgabevorgänge in Einheiten von Sektoren vorgenommen, wobei bei einem Neuschreiben des Inhalts des Flashspeichers 303 Daten in Blockeinheiten ein- oder ausgegeben werden (wobei jeder Block eine Größe von 32 Sektoren (16 KB) aufweist). Dies bedeutet insbesondere, dass beim Neuschreiben der Daten in einen Sektor der jeweilige Block aus dem Flashspeicher 303 gelesen und in dem Puffer in der jeweiligen Zugriffssteuereinheit gespeichert wird, der Block aus dem Flashspeicher gelöscht wird, der jeweilige Sektor in den Pufferspeicher neugeschrieben wird und der Block in dem Pufferspeicher anschließend zurück in den Flashspeicher 303 geschrieben wird.
Die Verschlüsselungs-/Entschlüsselungsschaltung 327 nimmt eine Verschlüsselung oder Entschlüsselung unter Verwendung des Masterkey 323a aus der Speicherung in der Masterkeyspeichereinheit 323 unter Steuerung der Authentisierungsbereichszugriffssteuereinheit 325 und der Nichtauthentisierungsbereichszugriffssteuereinheit 326 vor. Sollen Daten in den Flashspeicher 303 geschrieben werden, so verschlüsselt die Verschlüsselungs-/Entschlüsselungsschaltung 327 die Daten und schreibt sie in den Flashspeicher 303. Sollen Daten umgekehrt aus dem Flashspeicher 303 gelesen werden, so entschlüsselt die Verschlüsselungs-/Entschlüsselungsschaltung 327 die Daten. Die Verschlüsselungs-/Entschlüsselungsschaltung 327 ist vorgesehen, um zu verhindern, dass Anwender nichtautorisierte Handlungen vornehmen, so beispielsweise das Knacken der Flashspeicherkarte 31 und das direkte Analysieren des Inhaltes des Flashspeichers 33, um Passworte, die in dem Authentisierungsbereich gespeichert sind, zu ermitteln.
{69_70} Kommunikationssequenz beim Abspielen von AOBs
70 zeigt die Kommunikationssequenz, die abläuft, wenn eine mit der Flashspeicherkarte 31 verbundene Abspielvorrichtung den Verschlüsselungsschlüssel FileKey liest und ein AOB abspielt.
Die Abspielvorrichtung gibt einen Befehl an die Flashspeicherkarte 31 (sc1), durch den der Masterkey gelesen wird. Sobald dieser Befehl gegeben ist, ermittelt die Befehlsdecodiereinheit 322 den verschlüsselten Masterkey 323b, der in der Masterkeyspeichereinheit 323 gespeichert ist, und gibt diesen an die Abspielvorrichtung aus (sc2).
Die Abspielvorrichtung, die die sichere Medienkennung empfängt, verwendet den Vorrichtungskey 211, den es selbst speichert, zur Entschlüsselung der sicheren Medienkennung (sc3). Der Entschlüsselungsalgorithmus, der in dem Entschlüsselungsprozess verwendet wird, entspricht dem Verschlüsselungsalgorithmus, der bei der Erzeugung des verschlüsselten Masterkey 323 verwendet wird, der auf der Flashspeicherkarte 31 gespeichert ist, sodass für den Fall, dass der Vorrichtungskey 211a, der von der Abspielvorrichtung verwendet wird, ein Schlüssel ist, dessen Verwendung erwartet wird (so beispielsweise der richtige Schlüssel), die Abspielvorrichtung in der Lage ist, den Masterkey durch Ausführen der Entschlüsselung erfolgreich zu ermitteln.
Nach Empfangen des Masterkey gibt die Abspielvorrichtung einen Spezialbefehl an die Flashspeicherkarte 31 aus, damit die Medienkennung gelesen wird (sc4). Die Spezialbereichszugriffssteuereinheit 324 erhält die Medienkennung aus dem ROM 304 der Flashspeicherkarte 31 und leitet sie an die Abspielvorrichtung weiter (sc5). Die Verschlüsse lungs-/Entschlüsselungsschaltung 327 verschlüsselt anschließend die Medienkennung unter Verwendung des Masterkey aus der Ermittlung durch den vorbeschriebenen Entschlüsselungsprozess (sc6). Der für diese Verschlüsselung verwendete Algorithmus ist derselbe wie derjenige Algorithmus, der zur Erzeugung der sicheren Medienkennung 363, die auf der Flashspeicherkarte 31 gespeichert ist, verwendet worden ist. Im Ergebnis ergibt sich eine sichere Medienkennung, die dieselbe wie die sichere Medienkennung 343 der Flashspeicherkarte 31 ist.
Die Abspielvorrichtung, die die Ermittlung einer sicheren Medienkennung erfolgreich vorgenommen hat, nimmt anschließend die wechselseitige Authentisierung mit der Authentisierungseinheit 321 der Flashspeicherkarte 31 vor (sc7). Dieser Prozess führt dazu, dass sowohl die Abspielvorrichtung wie auch die Authentisierungseinheit 321 (a) über Information (OK/NG), durch die gezeigt wird, ob die andere Vorrichtung erfolgreich authentisiert worden ist, und (b) über einen zeitveränderlichen sicheren Schlüssel, dessen Inhalt von dem Authentisierungsergebnis abhängt, verfügen.
Ist die wechselseitige Authentisierung erfolgreich abgeschlossen, so erzeugt die Abspielvorrichtung einen Befehl für den Zugriff auf den Authentisierungsbereich der Flashspeicherkarte 31. Werden beispielsweise Daten aus dem Authentisierungsbereich gelesen, so verschlüsselt die Abspielvorrichtung die Parameter (das heißt eine 24 Bit umfassende Adresse „Address" und eine 8 Bit umfassende Datenlänge „count") des Befehls „SecureRead address count" unter Verwendung des sicheren Schlüssels (sc8) und verknüpft diese Parameter mit dem Tag dieses Befehls (das heißt einem 6 Bit umfassenden Code, der zeigt, dass dieser Befehl „SecureRead" ist), um einen verschlüsselten Befehl zu erzeugen (sc9), den die Abspielvorrichtung an die Flashspeicherkarte 31 sendet (sc10).
Beim Empfangen des verschlüsselten Befehls identifiziert die Flashspeicherkarte 31 die Art von Befehl aus dem Tag (sc11). Beim vorliegenden Beispiel identifiziert die Flashspeicherkarte 31, dass der Befehl „SecureRead" für einen Lesevorgang von dem Authentisierungsbereich ist.
Ist der Lesebefehl identifiziert worden, so entschlüsselt die Verschlüsselungs-/Entschlüsselungsschaltung 327 die Parameter, die in dem Befehl enthalten sind, unter Verwendung des sicheren Schlüssels (sc12), den man durch die wechselseitige Authentisierung (sc13) erhalten hat.
Der zur Entschlüsselung der Parameter verwendete Algorithmus entspricht dem Verschlüsselungsalgorithmus, der von der Abspielvorrichtung bei der Erzeugung des verschlüsselten Befehls verwendet worden ist, sodass bei erfolgreicher wechselseitiger Authentisierung, was bedeutet, dass der sichere Schlüssel in der Flashspeicherkarte 31 dem sicheren Schlüssel in der Abspielvorrichtung entspricht, die durch diese Entschlüsselung ermittelten Parameter diejenigen Parameter sind, die von der Abspielvorrichtung verwendet werden.
Bei Empfang eines Befehls, der diese gültigen Parameter enthält, greift die Authentisierungsbereichszugriffssteuereinheit 325 auf diejenigen Sektoren zu, die durch die gültigen Parameter spezifiziert sind, und liest den in diesen Sektoren gespeicherten Verschlüsselungsschlüssel FileKey aus dem Authentisierungsbereich. Die Verschlüsselungs-/Entschlüsselungsschaltung 327 verschlüsselt den in der Datei „AOBSA1.KEY" gespeicherten Verschlüsselungsschlüssel FileKey in dem Authentisierungsbereich (sc15) unter Verwendung des sicheren Schlüssels (sc14), der während der wechselseitigen Authentisierung ermittelt worden ist. Anschließend sendet die Authentisierungsbereichszugriffssteuereinheit 325 den in der Datei „AOBSA1.KEY" gespeicherten Verschlüsselungsschlüssel FileKey in dem Authentisierungsbeeich an die Abspielvorrichtung (sc16).
Die Abspielvorrichtung entschlüsselt (sc18) den Verschlüsselungsschlüssel FileKey, den sie empfangen hat, unter Verwendung des sicheren Schlüssels (sc17), der während der wechselseitigen Authentisierung ermittelt worden ist. Der Verschlüsselungsalgorithmus, der hier verwendet wird, entspricht dem Algorithmus, der von der Flashspeicherkarte 31 verwendet wird, um den Verschlüsselungsschlüssel FileKey zu entschlüsseln, weshalb der ursprüngliche Verschlüsselungsschlüssel FileKey ermittelt werden kann. Anschließend wird der ermittelte Verschlüsselungsschlüssel FileKey unter Verwendung des Masterkey 323b und der Medienkennung entschlüsselt, um den Verschlüsselungsschlüssel FileKey zu ermitteln (sc20).
Sobald der Verschlüsselungsschlüssel FileKey ermittelt worden ist und ein AOB entsprechend dem Verschlüsselungsschlüssel FileKey aus dem Nichtauthentisierungsbereich gelesen worden ist (sc21), wird das AOB unter Verwendung des Verschlüsselungsschlüssels FileKey entschlüsselt, und es wird gleichzeitig Musik abgespielt.
{69_70_71} Detaillierte Kommunikationssequenz unter Verwendung einer wechselseitigen Authentisierung
71 zeigt die Kommunikationssequenz, die während der wechselseitigen Authentisierung von 70 verwendet wird, im Detail. Bei diesem Beispiel nehmen die Flashspeicherkarte 31 und die Abspielvorrichtung eine wechselseitige Authentisierung im Challenge-Response-Format vor.
Die Autorisierungseinheit 321 auf der Flashspeicherkarte 31 erzeugt eine Zufallszahl, um die Authentizität der Abspielvorrichtung zu testen (sc30), und sendet diese Zufallszahl an die Abspielvorrichtung als Challenge-Daten (sc50). Um die eigene Authentizität nachzuweisen, verschlüsselt die Abspielvorrichtung die Challenge-Daten (sc31) und sendet das Ergebnis an die Autorisierungseinheit 321 auf der Flashspeicherkarte 31 als Response-Daten (sc32). Die Autorisierungseinheit 321 auf der Flashspeicherkarte 31 verschlüsselt die gesendete Zufallszahl als Challenge-Daten (sc33) und vergleicht diese verschlüsselte Zufallszahl mit den Response-Daten (sc34).
Entsprechen die verschlüsselte Zufallszahl und die Response-Daten einander, so wird die Abspielvorrichtung authentisiert (OK), und die Flashspeicherkarte 31 ermöglicht daraufhin auf den Authentisierungsbereich zugreifende Zugriffsbefehle, die sie von der Abspielvorrichtung empfängt. Entsprechen demgegenüber die verschlüsselte Zufallszahl und die Response-Daten einander nicht, so wird die Abspielvorrichtung nicht authentisiert und die Flashspeicherkarte 31 weist von der Abspielvorrichtung empfangene Zugriffsbefehle für den Authentisierungsbereich zurück.
Dieselbe Authentisierungsprozedur wird von der Abspielvorrichtung für eine Verifizierung dahingehend vorgenommen, dass die Flashspeicherkarte 31 authentisch ist.
Mit anderen Worten, es erzeugt die Abspielvorrichtung eine Zufallszahl (sc40) und sendet diese Zufallszahl an die Autorisierungseinheit 321 auf der Flashspeicherkarte 31 als Challenge-Daten (sc51). Um die Authentizität der Flashspeicherkarte 31 nachzuweisen, verschlüsselt die Autorisierungseinheit 321 die Challenge-Daten (sc41) und sendet das Ergebnis an die Abspielvorrichtung als Response-Daten (sc42).
Die Abspielvorrichtung verschlüsselt die gesendete Zufallszahl als Challenge-Daten (sc43) und vergleicht die verschlüsselte Zufallszahl mit den Response-Daten (sc44).
Entsprechen die verschlüsselte Zufallszahl und die Response-Daten einander, so wird die Flashspeicherkarte 31 authentisiert (OK) und die Abspielvorrichtung kann anschließend Zugriffe auf den Authentisierungsbereich der Flashspeicherkarte 31 vornehmen. Entsprechen demgegenüber die verschlüsselte Zufallszahl und die Response-Daten einander nicht, so wird die Flashspeicherkarte 31 nicht authentisiert (NG) und die Abspielvorrichtung kann keine Zugriffe auf den Authentisierungsbereich der Flashspeicherkarte 31 vornehmen.
Sind die Flashspeicherkarte 31 und die Abspielvorrichtung authentisiert, so wird von beiden Seiten derselbe Verschlüsselungsalgorithmus bei der wechselseitigen Authentisierung verwendet. Die Flashspeicherkarte 31 und die Abspielvorrichtung nehmen beide ein logisches exklusives ODER (XOR) an den beiden verschlüsselten Zufallszahlen vor (das heißt an der verschlüsselten Zufallszahl, die an die andere Seite als Challenge-Daten gesendet wurde, und an der verschlüsselten Zufallszahl, die zur Prüfung der empfangenen Response-Daten gesendet wurde), die bei den Prozessen der wechselseitigen Authentisierung verwendet worden sind (sc45, sc46), wobei das Ergebnis des XOR als sicherer Schlüssel eingestellt wird, der beim Zugriff auf den Authentisierungsbereich der Flashspeicherkarte 31 verwendet wird. Auf diese Weise wird derselbe sichere Schlüssel auf der Flashspeicherkarte 31 und in der Abspielvorrichtung nur dann eingestellt, wenn die wechselseitige Authentisierung erfolgreich vorgenommen worden ist. Da ein sicherer Schlüssel, der zeitveränderlich ist (das heißt nur für die aktuelle Sitzung verwendet werden kann) auf diese Weise beidseitig verwendet werden kann, ist die erfolgreiche Ausführung der wechselseitigen Authentisierungsprozedur als Voraussetzung für einen Zugriff auf den Authentisierungsbereich erforderlich.
Als Alternative kann jede Seite den sicheren Schlüssel durch Bilden eines logischen oder der verschlüsselten Challenge-Daten gemäß Erzeugung durch jene Seite, der Response-Daten gemäß Empfang von der anderen Seite und der sicheren Medienkennung erzeugen.
Die vorbeschriebenen Ausführungsbeispiele greifen auf Daten, die im Zusammenhang mit dem Schutz von Urheberrechten stehen und sich in dem Authentisierungsbereich befinden, und andere Daten, die sich in dem Nichtauthentisierungsbereich befinden, zu. Dies ermöglicht die Verwirklichung einer Halbleiterspeicherkarte, die in der Lage ist, gleichzeitig sowohl digitale Produktionen, deren Urheberrechte geschützt werden müs sen, wie auch digitale Produktionen, die derartigen Einschränkungen nicht unterliegen, zu speichern.
Ungeachtet der Tatsache, dass die vorliegende Erfindung anhand eines Beispieles unter Bezugnahme auf die begleitende Zeichnung vollständig beschrieben worden ist, beachte man, dass für einen Fachmann auf dem einschlägigen Gebiet verschiedenartige Abwandlungen und Änderungen offenkundig sind.

Claims

Halbleiter-Speicherkarte (31), die wenigstens eine Audio-Spur speichert, gekennzeichnet durch einen geschützten Bereich, auf den durch eine Vorrichtung, die mit der Halbleiter-Speicherkarte (31) verbunden ist, nur zugegriffen werden kann, wenn sich die Vorrichtung als authentisch erwiesen hat, wobei der geschützte Bereich eine Verschlüsselungsschlüssel-Sequenz (FileKey Entries #1, #2, #3 ...) speichert, die aus einer Vielzahl von Verschlüsselungsschlüsseln zusammengesetzt ist, die in einer vorgegebenen Reihenfolge angeordnet sind; und einen ungeschützten Bereich, auf den durch jede beliebige Vorrichtung zugegriffen werden kann, die mit der Halbleiter-Speicherkarte verbunden ist, wobei der ungeschützte Bereich wenigstens eine Audio-Spur (Tracks A-E) und Verwaltungsinformationen (TKI#1, #2, #3 ...) speichert, die wenigstens eine Audio-Spur (Tracks A-E) eine Vielzahl verschlüsselter Audio-Objekte (AOB001.SA1, AOB002.SA1, ...) enthält, und die Verwaltungsinformationen (TKI#1, #2, #3 ...) zeigen, welcher Verschlüsselungsschlüssel der Vielzahl von Verschlüsselungsschlüsseln jedem Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) entspricht, das in dem ungeschützten Bereich gespeichert ist.
Halbleiter-Speicherkarte nach Anspruch 1, wobei die Verwaltungsinformationen (TKI#1, #2, #3 ...), für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) eine Speicherposition des Audio-Objektes (AOB001.SA1, AOB002.SA1, ...) und eine Zahl zeigen, die eine Position des Verschlüsselungsschlüssels, der dem Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) entspricht, in der Verschlüsselungsschlüssel-Sequenz zeigt.
Halbleiter-Speicherkarte nach Anspruch 2, wobei jede Audio-Spur (Tracks A-E) des Weiteren enthält: (1) Attributinformationen (TKLL_BLK_ATR) und (2) Verknüpfungsinformationen (TKI_LNK_PTR) für jedes Audio-Objekt, das in der Audio-Spur enthalten ist, und die Attributinformationen (TKI_BLK_ATR) einen Typ von Typ (a), Typ (b), Typ (c) und Typ (d) für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) zeigen, und Typ (a) eine gesamte Audio-Spur (Tracks A-E) ist, Typ (b) ein erster Teil einer Audio-Spur (Tracks (A_E) ist, Typ (c) ein Mittelteil einer Audio-Spur (Tracks A-E) ist, und Typ (d) ein Endteil einer Audio-Spur (Tracks A-E) ist, und die Verknüpfungsinformationen (TKI_LNK_PTR) für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...), das Typ (b) oder Typ (c) ist, zeigen, welches Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) auf das Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) folgt.
Halbleiter-Speicherkarte nach Anspruch 3, wobei die Vielzahl von Audio-Objekten (AOB001.SA1, AOB002.SA1, ...) enthält: wenigstens ein Audio-Objekt (AOB001.SA1, AOB002.SA1, ...), das nur gültige Daten enthält, die abgespielt werden müssen; und wenigstens ein Audio-Objekt (AOB001.SA1, AOB002.SA1, ...), das 1. gültige Daten und 2. ungültige Daten enthält, die sich wenigstens entweder vor oder nach den gültigen Daten befinden, wobei die ungültigen Daten nicht abgespielt werden müssen, jede Audio-Spur (Tracks A-E) des Weiteren Blockinformationen für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) in der Audio-Spur (Tracks A-E) enthält, und die Blockinformationen enthalten: einen Offset, gemessen von der Speicherposition des entsprechenden Audio-Objektes (AOB001.SA1, AOB002.SA1, ...), die in den Verwaltungsinformationen (TKI#1, #2, #3 ...) gegeben ist; und Längeninformationen, die eine Länge der gültigen Daten zeigen, die an einer Position beginnt, die durch den Offset angezeigt wird, wobei die Attributinformationen (TKI_BLK_ATR) für ein Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) zeigen, ob die durch den Offset und die Längeninformationen angezeigten gültigen Daten (a) einer gesamten Audio-Spur (Tracks A-E) entsprechen, (b) einem ersten Teil einer Audio-Spur (Tracks A-E) entsprechen, (c) einem mittleren Teil einer Audio-Spur (Tracks A-E) entsprechen, oder (d) einem Endteil einer Audio-Spur (Tracks A-E) entsprechen.
Halbleiter-Speicherkarte nach Anspruch 4, wobei Audio-Spuren (Tracks A-E) entsprechend einem Standard-Abspielen oder einem intermittierenden Abspielen abgespielt werden können, das Standard-Abspielen ein Modus ist, in dem die gültigen Daten in Audio-Objekten (AOB001.SA1, AOB002.SA1, ...), die die Audio-Spuren (Tracks A-E) bilden, abgespielt werden, ohne dass gültige Daten weggelassen werden, und das intermittierende Abspielen ein Modus ist, in dem 1. Weglassen gültiger Daten, die einer ersten Periode äquivalent sind, und 2. Abspielen gültiger Daten, die einer zweiten Periode äquivalent sind, wiederholt werden, jede Audio-Spur (Tracks A-E) des Weiteren eine Vielzahl von Elementen von Eintragspositionsinformationen (TMSRT_entries #1, #2, #3, ...) enthält, die interne Positionen der gültigen Daten innerhalb des Audio-Objektes (AOB001.SA1, AOB002.SA1, ...) in Intervallen zeigen, die der ersten Periode äquivalent sind, und die Blockinformationen für ein Objekt (AOB001.SA1, AOB002.SA1, ...) zeigen: den Offset, der einen Unterschied zwischen 1. der internen Position, die durch ein erstes Element von Eintragspositionsinformationen (TMSRT_entries #1, #2, #3, ...) für das Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) gezeigt wird, und 2. der Speicherposition für das Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) anzeigt, die in den Verwaltungsinformationen (TKI#1, #2, #3 ...) gegeben ist; und eine Länge der gültigen Daten, die an einer durch den Offset angezeigten Position beginnt.
Abspielvorrichtung zum Lesen und Abspielen von Audio-Spuren (Tracks A-E) von der Halbleiterkarte (31) nach Anspruch 1, wobei die Abspielvorrichtung gekennzeichnet ist durch: eine Leseeinrichtung zum Lesen eines der Vielzahl von Audio-Objekten (AOB001.SA1, AOB002.SA1, ...), das in der wenigstens einen Audio-Spur (Tracks A-E) enthalten ist, aus dem ungeschützten Bereich der Halbleiter-Speicherkarte (31) und zum Lesen eines Verschlüsselungsschlüssels, der dem gelesenen Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) entspricht, aus der Verschlüsselungsschlüssel-Sequenz (FileKey Entries #1, #2, #3 ...), die in dem geschützten Bereich der Halbleiter-Speicherkarte (31) enthalten ist; eine Entschlüsselungseinrichtung (7) zum Entschlüsseln des gelesenen Audio-Objektes (AOB001.SA1, AOB002.SA1, ...) unter Verwendung des gelesenen Verschlüsselungsschlüssels; und eine Abspieleinrichtung (8) zum Abspielen des entschlüsselten Audio-Objektes (AOB001.SA1, AOB002.SA1, ...), wobei, wenn die Entschlüsselungseinrichtung Entschlüsseln des gelesenen Audio-Objektes (AOB001.SA1, AOB002.SA1, ...) beendet hat, die Leseeinrichtung ein anderes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) liest, das in einer Audio-Spur (Tracks A-E) enthalten ist, einen Verschlüsselungsschlüssel, der dem anderen Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) entspricht, aus der Verschlüsselungsschlüssel-Sequenz (FileKey Entries #1, #2, #3 ...) liest, und den neu gelesenen Verschlüsselungsschlüssel der Entschlüsselungseinrichtung (7) zuführt.
Aufzeichnungsvorrichtung zum Aufzeichnen eines Titels, der aus einer Vielzahl von Inhalten zusammengesetzt ist, auf eine Halbleiter-Speicherkarte (31), um die Halbleiter-Speicherkarte (31) nach Anspruch 1 zu erhalten, wobei die Aufzeichnungsvorrichtung gekennzeichnet ist durch: eine Verschlüsselungseinrichtung (26) zum Zuweisen wenigstens eines einer Vielzahl von Verschlüsselungsschlüsseln zu jedem im dem Titel enthaltenen Inhalt und zum Verschlüsseln jedes Inhaltes unter Verwendung der den Inhalten zugewiesenen Verschlüsselungsschlüssel, um eine Vielzahl von Audio-Objekten (AOB001.SA1, AOB002.SA1, ...) zu erzeugen; und eine Aufzeichnungseinrichtung (21), die in den geschützten Bereich der Halbleit er-Speicherkarte (31) die Vielzahl von Verschlüsselungsschlüsseln als eine Verschlüsselungsschlüssel-Sequenz (FileKey Entries #1, #2, #3 ...) aufzeichnet, und in den ungeschützten Bereich der Halbleiter-Speicherkarte (31) die Vielzahl von Audio-Objekten (AOB001.SA1, AOB002.SA1, ...) als wenigstens eine Audio-Spur (TKI#1, #2, #3) zusammen mit den Verwaltungsinformationen aufzeichnet, die der wenigstens einen Audio-Spur (Tracks A-E) entsprechen.
Aufzeichnungsvorrichtung nach Anspruch 7, wobei nach Aufzeichnen der Vielzahl von Verschlüsselungsschlüsseln und der Vielzahl der Audio-Objekten (ROB001.SA1, AOB002.SA1, ...) die durch die Aufzeichnungseinrichtung (21) aufgezeichneten Verwaltungsinformationen (TKI#1, #2, #3 ...) für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1,...) Entsprechung zwischen einem Bereich auf der Halbleiter-Speicherkarte (31), der das Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) speichert, und einer Speicherposition des Verschlüsselungsschlüssels zeigt, der dem Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) entspricht.
Aufzeichnungsvorrichtung nach Anspruch 8, wobei für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) die Aufzeichnungseinrichtung (21) auch Attributinformationen (TKI_BLK_ATR) und Verknüpfungsinformationen (TKI_LNK_PTR) auf die Halbleiter-Speicherkarte (31) aufzeichnet, und die Attributinformationen (TKI_BLK_ATR) für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) einen Typ von einem Typ (a), Typ (b), Typ (c) und Typ (d) zeigen, und Typ (a) eine gesamte Audio-Spur (Tracks A-E) ist, Typ (b) ein erster Teil einer Audio-Spur (Tracks A-E) ist, Typ (c) ein Mittelteil einer Audio-Spur (Tracks A-E) ist, und Typ (d) ein Endteil einer Audio-Spur (Tracks A-E) ist, und die Verknüpfungsinformationen (TKI_LNK_PTR) für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1,...), das Typ (b) oder Typ (c) ist, zeigen, welches Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) auf das Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) folgt.
Aufzeichnungsvorrichtung nach Anspruch 7, wobei jedes der Vielzahl von Audio-Objekten in einer einzelnen Datei in dem ungeschützten Bereich der Halbleiter-Speicherkarte (31) gespeichert ist, und die Aufzeichnungsvorrichtung gekennzeichnet ist durch: eine Codiereinrichtung (25) zum aufeinanderfolgenden Erzeugen von Audio-Frames aus einem Eingangssignal, das von außerhalb der Aufzeichnungsvorrichtung empfangen wird, wobei ein Audio-Frame eine kleinste Datenmenge ist, die unabhängig decodiert werden kann; eine Erzeugungseinrichtung (28) zum Erzeugen eines Elementes von Eintragsinformationen, das eine Datenlänge eines Audio-Elementes zeigt, das aus einer vorgegebenen Anzahl von Audio-Frames zusammengesetzt ist, und wobei, wenn eine vorgegebene Anzahl von Elementen von Eintragsinformationen erzeugt ist, die Aufzeichnungseinrichtung (21) eine neue Datei in dem ungeschützten Bereich der Halbleiter-Speicherkarte (31) erzeugt und die Audio-Frames, die danach aufeinanderfolgend durch die Codiereinrichtung erzeugt werden, in die neue Datei schreibt.
Wiedergabeverfahren zum Lesen und Abspielen einer Vielzahl von Audio-Spuren (Tracks A-E) von der Halbleiter-Speicherkarte (31) nach Anspruch 1, wobei das Verfahren gekennzeichnet ist durch: einen Leseschritt zum Lesen eines der Vielzahl von Audio-Objekten (AOB001.SA1, AOB002.SA1, ...), das in der wenigstens einen Audio-Spur enthalten ist, von der Halbleiter-Speicherkarte (31) und zum Lesen eines Verschlüsselungsschlüssels, der dem gelesenen Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) entspricht, aus der Verschlüsselungsschlüssel-Sequenz (FileKey Entries #1, #2, #3 ...), die in dem geschützten Bereich der Halbleiter-Speicherkarte (31) gespeichert ist; einen Entschlüsselungsschritt zum Entschlüsseln des gelesenen Audio-Objektes (AOB001.SA1, AOB002.SA1, ...) unter Verwendung des gelesenen Verschlüsselungsschlüssels; und einen Abspielschritt zum Abspielen des entschlüsselten Audio-Objektes (AOB001.SA1, AOB002.SA1, ...), wobei, wenn der Entschlüsselungsschritt Entschlüsseln des gelesenen Audioobjektes (AOB001.SA1, AOB002.SA1, ...) beendet hat, der Leseschritt ein anderes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) liest, das in einer Audio-Spur (Tracks A-E) enthalten ist, einen Verschlüsselungsschlüssel, der dem anderen Audioobjekt (AOB001.SA1, AOB002.SA1, ...) entspricht, aus der Verschlüsselungsschlüssel-Sequenz (FileKey Entries #1, #2, #3 ...) liest, und den neu gelesenen Verschlüsselungsschlüssel dem Entschlüsselungsschritt zuführt.
Aufzeichnungsverfahren zum Aufzeichnen eines Titels, der aus einer Vielzahl von Inhalten zusammengesetzt ist, auf eine Halbleiter-Speicherkarte, um die Halbleiter-Speicherkarte (31) nach Anspruch 1 zu erhalten, wobei das Verfahren gekennzeichnet ist durch: einen Verschlüsselungsschritt zum Zuweisen wenigstens eines einer Vielzahl von Verschlüsselungsschlüsseln zu jedem in dem Titel enthaltenen Inhalt und zum Verschlüsseln jedes Inhaltes unter Verwendung der den Inhalten zugewiesenen Verschlüsselungsschlüssel, um eine Vielzahl von Audio-Objekten (AOB001.SA1, AOB002.SA1, ...) zu erzeugen; einen Aufzeichnungsschritt zum: Aufzeichnen der Vielzahl von Verschlüsselungsschlüsseln als eine Verschlüsselungsschlüssel-Sequenz (FileKey Entries #1, #2, #3 ...) in den geschützten Bereich der Halbleiter-Speicherkarte (31), und Aufzeichnen der Vielzahl von Audio-Objekten (AOB001.SA1, AOB002.SA1, ...) als wenigstens eine Audio-Spur zusammen mit Verwaltungsinformationen (TKI#1, #2, #3 ...), die der Audio-Spur (Tracks A-E) entsprechen, in den ungeschützten Bereich der Halbleiter-Speicherkarte (31).
Aufzeichnungsverfahren nach Anspruch 12, wobei nach Aufzeichnen der Vielzahl von Verschlüsselungsschlüsseln und der Vielzahl von Audio-Objekten (AOB001.SA1, AOB002.SA1, ...) die in dem Aufzeichnungsschritt aufgezeichneten Verwaltungsinformationen (TKI#1, #2, #3 ...) für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) Entsprechung zwischen einem Bereich auf der Halbleiter-Speicherkarte (31), die das Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) speichert, und einer Speicherposition des Verschlüsselungsschlüssels zeigen, der dem Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) entspricht.
Aufzeichnungsverfahren nach Anspruch 13, wobei für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) der Aufzeichnungsschritt auch Attributinformationen (TKI_BLK_ATR) und Verknüpfungsinformationen (TKI_LNK_PTR) auf die Halbleiter-Speicherkarte (31) aufzeichnet, und die Attributinformationen (TKI_BLK_ATR) für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) einen Typ von Typ (a), Typ (b), Typ (c) und Typ (d) zeigen, und Typ (a) eine gesamte Audio-Spur (Tracks A-E) ist, Typ (b) ein erster Teil einer Audio-Spur (Tracks A-E) ist, Typ (c) ein Mittelteil einer Audio-Spur (Tracks A-E) ist, und Typ (d) ein Endteil einer Audio-Spur (Tracks A-E) ist, und die Verknüpfungsinformationen (TKI_LNK_PTR) für jedes Audio-Objekt (AOB001.SA1, AOB002.SA1, ...), das Typ (b) oder Typ (c) ist, zeigen, welches Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) auf das Audio-Objekt (AOB001.SA1, AOB002.SA1, ...) folgt.
Aufzeichnungsverfahren nach Anspruch 12, wobei jedes der Vielzahl von Audio-Objekten (AOB001.SA1, AOB002.SA1, ...) in einer einzelnen Datei in dem unge schützten Bereich der Halbleiter-Speicherkarte (31) aufgezeichnet wird und das Verfahren gekennzeichnet ist durch: einen Codierschritt zum aufeinanderfolgenden Erzeugen von Audio-Frames aus einem Eingangssignal, das von außerhalb der Aufzeichnungsvorrichtung empfangen wird, wobei ein Audio-Frame eine kleinste Datenmenge ist, die unabhängig decodiert werden kann; einen Erzeugungsschritt zum Erzeugen eines Elementes von Eintragsinformationen, das eine Datenlänge eines Audio-Elementes zeigt, das aus einer vorgegebenen Anzahl von Audio-Frames zusammengesetzt ist, und wobei, wenn eine vorgegebene Anzahl von Elementen von Eintragsinformationen erzeugt ist, der Aufzeichnungsschritt eine neue Datei in dem ungeschützten Bereich der Halbleiter-Speicherkarte (31) erzeugt und die Audio-Frames, die danach aufeinanderfolgend in dem Codierschritt erzeugt werden, in die neue Datei schreibt.
Computerlesbares Aufzeichnungsmedium, das Code umfasst, der ausgeführt werden kann, um einen Computer zu veranlassen, das Abspielverfahren nach Anspruch 11 durchzuführen.
Computerlesbares Aufzeichnungsmedium, das Code umfasst, der ausgeführt werden kann, um einen Computer zu veranlassen, das Aufzeichnungsverfahren nach einem der Ansprüche 12-15 durchzuführen.