Recherche avancée

Sur d’autres sites (3948)

• Diamond Rio Artifacts

  30 août 2012, par Multimedia Mike — Multimedia History

  Remember the Diamond Rio PMP300 ? It’s credited with being the very first portable MP3 player, released all the way back in 1998 (I say ‘credited’ because I visited an audio museum once which exhibited a Toshiba MP3 player from 1997). I recently rescued a pristine set of Rio artifacts from a recycle pile.

  
  
  

  I wondered if I should scan the manual for posterity. However, a Google search indicates that a proper PDF (loaded with pleas to not illegally copy music) isn’t very difficult to come by. Here are the other items that came with the unit :

  
  
  Click for larger image
  

  Ah, more memories (of dialup internet) : A tie-in with another Diamond product, this time a modem which claims to enable the user to download songs at up to 112 kilobits per second. I wonder if that was really possible. I remember that 56k modems were a stretch and 33.6k was the best that most users could hope for.

  There is also a separate piece of paper that advises the buyer that the parallel port adapter might look a bit different than what is seen in the printed copy. Imagine the age of downloading to your MP3 player via parallel port while pulling down new songs via dialup internet.

  The artifacts also included not one, but two CD-ROMs :

  
  
  Click for larger image
  

  One is a driver and software disc, so no big surprise there. The other has a selection of MP3 files for your shiny new MP3 player. I’m wondering if these should be proactively preserved. I was going to process the files’ metadata and publish it here, for the benefit of search engines. However, while metadata is present, the files don’t conform to any metadata format that FFmpeg/Libav recognize. The files mention Brava Software Inc. in their metadata sections. Still, individual filenames at the end of this post.

  Leftovers :
  A few other miscellaneous multimedia acquisitions :

  
  
  

  I still want to study all of these old multimedia creation programs in depth some day. Theatrix Hollywood is a creative writing game, Wikipedia alleges (I’m a bit rigid with my exact definition of what constitutes a game). Here is an example movie output from this software. Meanwhile, the Mad Dog Multimedia CD-ROM apparently came packaged with a 56X CD-ROM drive (roughly the pinnacle of CD-ROM speeds). I found it has some version of Sonic Foundry’s ACID software, thus making good on the “applications” claim on the CD-ROM copy.

  Diamond Rio MP3 Sampler
  These are the names of the MP3 files found on the Diamond Rio MP3 sampler for the benefit of search engines.

  13_days.mp3
  albert_einstein_dreams.mp3
  a_man_of_many_colours.mp3
  anything_for_love.mp3
  a_secret_place.mp3
  bake_sale.mp3
  bigger_than_the_both_of_us.mp3
  boogie_beat.mp3
  bring_it_on.mp3
  buskersoundcheck_hippo.mp3
  charm.mp3
  chemical_disturbance.mp3
  coastin.mp3
  credit_is_due.mp3
  dance_again.mp3
  destiny.mp3
  dig_a_little_deeper.mp3
  diplomat6_bigmouthshut.mp3
  dirty_littlemonster.mp3
  dirty.mp3
  drivin.mp3
  Eric_Clapton_Last_Train.mp3
  etude_in_c_sharp_minor_op_42_n.mp3
  everybody_here.mp3
  freedom_4_all.mp3
  grandpas_advice.mp3
  groove.mp3
  heartland.mp3
  he_loved_her_so.mp3
  highway_to_hell.mp3
  hit_the_ground_runnin.mp3
  i_feel_fine_today.mp3
  im_not_lost_im_exploring.mp3
  into_the_void.mp3
  its_alright.mp3
  i_will_be_there.mp3
  i_will_pass_this_way_again.mp3
  juiceboxwilly_hepcat.mp3
  just_an_illusion.mp3
  keepin_time_by_the_river.mp3
  king_of_the_brooklyn_delta.mp3
  lovermilou_ringingbell.mp3
  middle_aged_rock_and_rollers.mp3
  midnight_high.mp3
  mr_schwinn.mp3
  my_brilliant_masterpiece.mp3
  my_gallery.mp3
  on_the_river_road.mp3
  pouring_rain.mp3
  prayer.mp3
  rats_in_my_bedroom.mp3
  razor_serpent_and_the_dub_mix.mp3
  ruthbuzzy_pleasestophangin.mp3
  secret_love.mp3
  ships.mp3
  silence_the_thunder.mp3
  sleeping_beauty.mp3
  slow_burn.mp3
  standing_in_my_own_way.mp3
  take_no_prisoners.mp3
  takin_up_space.mp3
  Taylor_Dayne_Unstoppable.mp3
  the_laundromat_song.mp3
  the_old_dun_cow.mp3
  the_people_i_meet.mp3
  trip_trigger_avenue.mp3
  tru-luv.mp3
  unfortunate_man.mp3
  vertigo.mp3
  when_she_runs.mp3
  where_do_we_go_from_here.mp3
  words_of_earnest.mp3
  

• Subtitling Sierra RBT Files

  2 juin 2016, par Multimedia Mike — Game Hacking

  This is part 2 of the adventure started in my Subtitling Sierra VMD Files post. After I completed the VMD subtitling, The Translator discovered a wealth of animation files in a format called RBT (this apparently stands for “Robot” but I think “Ribbit” format could be more fun). What are we going to do ? We had come so far by solving the VMD subtitling problem for Phantasmagoria. It would be a shame if the effort ground to a halt due to this.

  Fortunately, the folks behind the ScummVM project already figured out enough of the format to be able to decode the RBT files in Phantasmagoria.

  In the end, I was successful in creating a completely standalone tool that can take a Robot file and a subtitle file and create a new Robot file with subtitles. The source code is here (subtitle-rbt.c). Here’s what the final result looks like :

  
  
  “What’s in the refrigerator ?” I should note at this juncture that I am not sure if this particular Robot file even has sound or dialogue since I was conducting these experiments on a computer with non-working audio.
  

  The RBT Format
  I have created a new MultimediaWiki page describing the Robot Animation format based on the ScummVM source code. I have not worked with a format quite like this before. These are paletted animations which consist of a sequence of independent frames that are designed to be overlaid on top of static background. Because of these characteristics, each frame encodes its own unique dimensions and origin coordinate within the frame. While the Phantasmagoria VMD files are usually 288×144 (which are usually double-sized for the benefit of a 640×400 Super VGA canvas), these frames are meant to be plotted on a game field that was roughly 576×288 (288×144 doublesized).
  

  For example, 2 minimalist animation frames from a desk investigation Robot file :

  
  
  100×147

  
  101×149
  

  As for compression, my first impression was that the algorithm was the same as VMD. This is wrong. It evidently uses an unmodified version of a standard algorithm called Lempel-Ziv-Stac (LZS). It shows up in several RFCs and was apparently used in MS-DOS’s transparent disk compression scheme.

  Approach
  Thankfully, many of the lessons I learned from the previous project are applicable to this project, including : subtitle library interfacing, subtitling in the paletted colorspace, and replacing encoded frames from the original file instead of trying to create a new file.

  Here is the pitch for this project :

  • Create a C program that can traverse through an input file, piece by piece, and generate an output file. The result of this should be a bitwise identical file.
  • Adapt the LZS compression decoding algorithm from ScummVM into the new tool. Make the tool dump raw Portable NetMap (PNM) files of varying dimensions and ensure that they look correct.
  • Compress using LZS.
  • Stretch the frames and draw subtitles.
  • More compression. Find the minimum window for each frame.

  Compression
  Normally, my first goal is to decompress the video and store the data in a raw form. However, this turned out to be mathematically intractable. While the format does support both compressed and uncompressed frames (even though ScummVM indicates that the uncompressed path is yet unexercised), the goal of this project requires making the frames so large that they overflow certain parameters of the file.

  A Robot file has a sequence of frames and 2 tables describing the size of each frame. One table describes the entire frame size (audio + video) while the second table describes just the video frame size. Since these tables only use 16 bits to specify a size, the maximum frame size is 65536 bytes. Leaving space for the audio portion of the frame, this only leaves a per-frame byte budget of about 63000 bytes for the video. Expanding the frame to 576×288 (165,888 pixels) would overflow this limit.

  Anyway, the upshot is that I needed to compress the data up front.

  Fortunately, the LZS compressor is pretty straightforward, at least if you have experience writing VLC-oriented codecs. While the algorithm revolves around back references, my approach was to essentially write an RLE encoder. My compressor would search for runs of data (plentiful when I started to stretch the frame for subtitling purposes). When a run length of n=3 or more of the same pixel is found, encode the pixel by itself, and then store a back reference of offset -1 and length (n-1). It took a little while to iron out a few problems, but I eventually got it to work perfectly.

  I have to say, however, that the format is a little bit weird in how it codes very large numbers. The length encoding is somewhat Golomb-like, i.e., smaller values are encoded with fewer bits. However, when it gets to large numbers, it starts encoding counts of 15 as blocks of 1111. For example, 24 is bigger than 7. Thus, emit 1111 into the bitstream and subtract 8 from 23 -> 16. Still bigger than 15, so stuff another 1111 into the bitstream and subtract 15. Now we’re at 1, so stuff 0001. So 24 is 11111111 0001. 12 bits is not too horrible. But the total number of bytes (value / 30). So a value of 300 takes around 10 bytes (80 bits) to encode.

  Palette Slices
  As in the VMD subtitling project, I took the subtitle color offered in the subtitle spec file as a suggestion and used Euclidean distance to match to the closest available color in the palette. One problem, however, is that the palette is a lot smaller in these animations. According to my notes, for the set of animations I scanned, only about 80 colors were specified, starting at palette index 55. I hypothesize that different slices of the palette are reserved for different uses. E.g., animation, background, and user interface. Thus, there is a smaller number of colors to draw upon for subtitling purposes.

  Scaling
  One bit of residual weirdness in this format is the presence of a per-frame scale factor. While most frames set this to 100 (100% scale), I have observed 70%, 80%, and 90%. ScummVM is a bit unsure about how to handle these, so I am as well. However, I eventually realized I didn’t really need to care, at least not when decoding and re-encoding the frame. Just preserve the scale factor. I intend to modify the tool further to take scale factor into account when creating the subtitle.

  The Final Resolution
  Right around the time that I was composing this post, The Translator emailed me and notified me that he had found a better way to subtitle the Robot files by modifying the scripts, rendering my entire approach moot. The result is much cleaner :

  
  
  Turns out that the engine supported subtitles all along
  

  It’s a good thing that I enjoyed the challenge or I might be annoyed at this point.

  See Also

  • Subtitling Sierra VMD Files : My effort to subtitle the main FMV files found in Sierra games.

• Why review compositing work in MJPEG videos rather than (say) H.264 ?

  6 juin 2016, par d3vid

  I have received a request to encode DPX files to MOV/MJPEG rather than MOV/H.264 (which ffmpeg picks by default if you convert to output.mov). These is to review compositing renders (in motion), so color accuracy is critical.

  Comparing a sample "ideal" MOV to the current (H.264) output I can see :

  • resolution : the same
  • ColorSpace/Primaries : Rec609 (SD) versus Rec709 (HD)
  • YUV : 4:2:0 versus 4:4:4
  • filesize : smaller

  The ffmpeg default seems to be better quality and result in a smaller filesize. Is there something I’m missing ?