Replaced several occurences of the word "media" by "medium"

libisoburn/trunk/xorriso/xorrisofs.info

@@ -196,13 +196,13 @@ then a new image is composed from scratch.
      Separated by a comma, set the next_writeable_address to which the
      add-on session will finally be written. Decisive is actually the
      block address which the intended readers will have to use as
-     superblock address on the intended media.
+     superblock address on the intended medium.
      Both values can be inquired from optical media by help of burn
      programs and cdrecord option -msinfo. xorriso itself can obtain it
      in its cdrecord emulation. Do not let it load the drive, but
      rather do this manually or by a program like dd which reads a few
      bytes. Only then it is sure that the device driver knows the true
-     readable size of the media.
+     readable size of the medium.
 
      dd if=/dev/... count=1 >/dev/null 2>&1
      values=$(xorriso -as cdrecord dev=/dev/... -msinfo)
@@ -610,7 +610,7 @@ characters from at most 3 characters.
      Conformant are ASCII characters out of [A-Z0-9_]. Like: "IMAGE_23"
      Joliet allows 16 UCS-2 characters. Like: "Windows name"
      Be aware that the volume id might get used automatically as name
-     of the mount point when the media is inserted into a playful
+     of the mount point when the medium is inserted into a playful
      computer system.
 
 -volid text
@@ -919,7 +919,7 @@ File: xorrisofs.info,  Node: Charset,  Next: Jigdo,  Prev: SystemArea,  Up: Opti
 
 Character sets should not matter as long as only english alphanumeric
 characters are used for file names or as long as all writers and readers
-of the media use the same character set.  Outside these constraints it
+of the medium use the same character set.  Outside these constraints it
 may be necessary to let xorriso convert byte codes.
 A conversion from input character set to the output character set is
 performed when an ISO image gets written.  Vice versa there is a
@@ -1169,11 +1169,11 @@ $ xorrisofs -M /dev/sr0 -C $m -graft-points \
 
 Always eject the drive tray between sessions. The old sessions get read
 via /dev/sr0. Its device driver might not be aware of the changed
-content before it loads the media again.  In this case the previous
+content before it loads the medium again.  In this case the previous
 session would not be loaded and the new session would contain only the
 newly added files.
-For the same reason do not let xorriso -as cdrecord load the media, but
-rather do this manually or by a program that reads from /dev/sr0.
+For the same reason do not let xorriso -as cdrecord load the medium,
+but rather do this manually or by a program that reads from /dev/sr0.
 
 
 File: xorrisofs.info,  Node: ExGrowisofs,  Next: ExIncBackup,  Prev: ExMkisofs,  Up: Examples
@@ -1222,11 +1222,11 @@ expected that inode numbers in the disk filesystem are persistent over
 cycles of mounting and booting.  Files with names matching *.o or *.swp
 get excluded explicitly.
 
-To be used several times on the same media, whenever an update of the
-two disk trees to the media is desired. Begin with blank media and start
-a new blank media when the run fails due to lack of remaining space on
-the old one.
-Do not let xorriso -as cdrecord load the media, but rather do this
+To be used several times on the same medium, whenever an update of the
+two disk trees to the medium is desired. Begin with a blank medium and
+update it until he run fails gracefully due to lack of remaining space
+on the old one.
+Do not let xorriso -as cdrecord load the medium, but rather do this
 manually or by a program that reads from /dev/sr0.
 
 $ dd if=/dev/sr0 count=1 >/dev/null 2>&1
@@ -1247,9 +1247,10 @@ full backup.
 *Better do not use your youngest backup for -old-root*.  Have at least
 two media which you use alternatingly. So only older backups get
 endangered by the new write operation, while the newest backup is
-stored safely on a different media.  Always have a blank media ready to
-perform a full backup in case the update attempt fails due to
-insufficient remaining capacity.
+stored safely on a different medium.
+Always have a blank medium ready to perform a full backup in case the
+update attempt fails due to insufficient remaining capacity. This
+failure will not spoil the old medium, of course.
 
 If inode numbers on disk are not persistent, then use option
 --old-root-no-ino .  In this case an update run will compare recorded
@@ -1304,7 +1305,7 @@ $ xorrisofs -root /session1 \
 
 With the second session, option -old-root refers to /session1 and the
 new -root is /session2.
-Do not let xorriso -as cdrecord load the media, but rather do this
+Do not let xorriso -as cdrecord load the medium, but rather do this
 manually or by a program that reads from /dev/sr0.
 
 $ dd if=/dev/sr0 count=1 >/dev/null 2>&1
@@ -1814,30 +1815,30 @@ Node: Insert3218
 Node: Xorriso4990
 Node: Options6129
 Node: Loading6846
-Node: SetInsert9140
-Node: SetProduct13556
-Node: SetCompl17263
-Node: SetExtras19582
-Node: SetHide22559
-Node: ImageId23558
-Node: Bootable27062
-Node: SystemArea31127
-Node: Charset37461
-Node: Jigdo38486
-Node: Miscellaneous42753
-Node: Examples43917
-Node: ExSimple44403
-Node: ExGraft44882
-Node: ExMkisofs46129
-Node: ExGrowisofs47380
-Node: ExIncBackup48552
-Node: ExIncBckAcc51601
-Node: ExBootable53276
-Node: Files55368
-Node: Seealso56442
-Node: Bugreport57098
-Node: Legal57679
-Node: CommandIdx58487
-Node: ConceptIdx69820
+Node: SetInsert9142
+Node: SetProduct13558
+Node: SetCompl17265
+Node: SetExtras19584
+Node: SetHide22561
+Node: ImageId23560
+Node: Bootable27065
+Node: SystemArea31130
+Node: Charset37464
+Node: Jigdo38490
+Node: Miscellaneous42757
+Node: Examples43921
+Node: ExSimple44407
+Node: ExGraft44886
+Node: ExMkisofs46133
+Node: ExGrowisofs47386
+Node: ExIncBackup48558
+Node: ExIncBckAcc51666
+Node: ExBootable53342
+Node: Files55434
+Node: Seealso56508
+Node: Bugreport57164
+Node: Legal57745
+Node: CommandIdx58553
+Node: ConceptIdx69886
 
 End Tag Table