Recherche avancée

Sur d’autres sites (3476)

• Zlib vs. XZ on 2SF

  21 juillet 2012, par Multimedia Mike — General, psf, saltygme, xz, zlib

  I recently released my Game Music Appreciation website. It allows users to play an enormous range of video game music directly in their browsers. To do this, the site has to host the music. And since I’m a compression bore, I have to know how small I can practically make these music files. I already published the results of my effort to see if XZ could beat RAR (RAR won, but only slightly, and I still went with XZ for the project) on the corpus of Super Nintendo chiptune sets. Next is the corpus of Nintendo DS chiptunes.

  Repacking Nintendo DS 2SF
  The prevailing chiptune format for storing Nintendo DS songs is the .2sf format. This is a subtype of the Portable Sound Format (PSF). The designers had the foresight to build compression directly into the format. Much of payload data in a PSF file is compressed with zlib. Since I already incorporated Embedded XZ into the player project, I decided to try repacking the PSF payload data from zlib -> xz.

  In an effort to not corrupt standards too much, I changed the ’PSF’ file signature (seen in the first 3 bytes of a file) to ’psf’.

  Results
  There are about 900 Nintendo DS games currently represented in my website’s archive. Total size of the original PSF archive, payloads packed with zlib : 2.992 GB. Total size of the same archive with payloads packed as xz : 2.059 GB.

  Using xz vs. zlib saved me nearly a gigabyte of storage. That extra storage doesn’t really impact my hosting plan very much (I have 1/2 TB, which is why I’m so nonchalant about hosting the massive MPlayer Samples Archive). However, smaller individual files translates to a better user experience since the files are faster to download.

  Here is a pretty picture to illustrate the space savings :

  
  
  

  The blue occasionally appears to dip below the orange but the data indicates that xz is always more efficient than zlib. Here’s the raw data (comes in vanilla CSV flavor too).

  Interface Impact
  So the good news for the end user is that the songs are faster to load up front. The downside is that there can be a noticeable delay when changing tracks. Even though all songs are packaged into one file for download, and the entire file is downloaded before playback begins, each song is individually compressed. Thus, changing tracks triggers another decompression operation. I’m toying the possibility of some sort of background process that decompresses song (n+1) while playing song (n) in order to help compensate for this.

  I don’t like the idea of decompressing everything up front because A) it would take even longer to start playing ; and B) it would take a huge amount of memory.

  Corner Case
  There was at least one case in which I found zlib to be better than xz. It looks like zlib’s minimum block size is smaller than xz’s. I think I discovered xz to be unable to compress a few bytes to a block any smaller than about 60-64 bytes while zlib got it down into the teens. However, in those cases, it was more efficient to just leave the data uncompressed anyway.

• Adding C64 SID Music

  1er novembre 2012, par Multimedia Mike — General

  I have been working on adding support for SID files — the music format for the Commodore 64 — to the game music website for awhile. I feel a bit out of my element since I’m not that familiar with the C64. But why should I let that slow me down ? Allow me to go through the steps I have previously outlined in order to make this happen.

  
  
  

  I need to know what picture should represent the system in the search results page. The foregoing picture should be fine, but I’m getting way ahead of myself.

  Phase 1 is finding adequate player software. The most venerable contender in this arena is libsidplay, or so I first thought. It turns out that there’s libsidplay (originally hosted at Geocities, apparently, and no longer on the net) and also libsidplay2. Both are kind of old (libsidplay2 was last updated in 2004). I tried to compile libsidplay2 and the C++ didn’t agree with current version of g++.

  However, a recent effort named libsidplayfp is carrying on the SID emulation tradition. It works rather well, notwithstanding the fact that compiling the entire library has a habit of apparently hanging the Linux VM where I develop this stuff.

  Phase 2 is to develop a testbench app around the playback library. With the help of the libsidplayfp library maintainers, I accomplished this. The testbench app consistently requires about 15% of a single core of a fairly powerful Core i7. So I look forward to recommendations that I port that playback library to pure JavaScript.

  Phase 3 is plug into the web player. I haven’t worked on this yet. I’m confident that this will work since phase 2 worked (plus, I have a plan to combine phases 2 and 3).

  One interesting issue that has arisen is that proper operation of libsidplayfp requires that 3 C64 ROM files be present (the, ahem, KERNAL, BASIC interpreter, and character generator). While these are copyrighted ROMs, they are easily obtainable on the internet. The goal of my project is to eliminate as much friction as possible for enjoying these old tunes. To that end, I will just bake the ROM files directly into the player.

  Phase 4 is collecting a SID song corpus. This is the simplest part of the whole process thanks to the remarkable curation efforts of the High Voltage SID Collection (HVSC). Anyone can download a giant archive of every known SID file. So that’s a done deal.

  Or is it ? One small issue is that I was hoping that the first iteration of my game music website would focus on, well, game music. There is a lot of music in the HVSC that are original compositions or come from demos. The way that the archive is organized makes it difficult to automatically discern whether a particular SID file comes from a game or not.

  Phase 5 is munging the metadata. The good news here is that the files have the metadata built in. The not-so-great news is that there isn’t quite as much as I might like. Each file is tagged with title, author, and publisher/copyright. If there is more than one song in a file, they all have the same metadata. Fortunately, if I can import them all into my game music database, there is an opportunity to add a lot more metadata.

  Further, there is no play length metadata for these files. This means I will need to set each to a default length like 2 minutes and do something like I did before in order to automatically determine if any songs terminate sooner.

  Oddly, the issue I’m most concerned about is character encoding. This is the first project for which I’m making certain that I understand character encoding since I can’t reasonably get away with assuming that everything is ASCII. So far, based on the random sampling of SID files I have checked, there is a good chance of encountering metadata strings with characters that are not in the lower ASCII set. From what I have observed, these characters map to Unicode code points. So I finally get to learn about manipulating strings in such a way that it preserves the character encoding. At the very least, I need Python to rip the strings out of the binary SID files and make sure the Unicode remains intact while being inserted into an SQLite3 database.

• Samsung S3 : 'Cannot play Video' on stock Video player

  18 mars 2013, par d33pika

  I am unable to play a mp4 video(H.264 Baseline, AAC) on Samsung S3, Android Version : 4.1.1, stock video player but plays on VLC. The same video plays on Galaxy Beam, Android Version : 2.3.6, stock Video Player. I want to figure out why it does not play on S3. I ran ffprobe and mediainfo on the fie :

  ffprobe results :

  ffprobe version 0.11.1 Copyright (c) 2007-2012 the FFmpeg developers
  
    built on Jan 25 2013 15:16:27 with llvm_gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
  
    configuration: --prefix=/usr/local/Cellar/ffmpeg/0.11.1 --enable-shared --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --cc=/usr/bin/llvm-gcc --host-cflags='-Os -w -pipe -march=core2 -msse4 -mmacosx-version-min=10.7' --host-ldflags=-L/usr/local/lib --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid
  
    libavutil      51. 54.100 / 51. 54.100
  
    libavcodec     54. 23.100 / 54. 23.100
  
    libavformat    54.  6.100 / 54.  6.100
  
    libavdevice    54.  0.100 / 54.  0.100
  
    libavfilter     2. 77.100 /  2. 77.100
  
    libswscale      2.  1.100 /  2.  1.100
  
    libswresample   0. 15.100 /  0. 15.100
  
    libpostproc    52.  0.100 / 52.  0.100
  
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '86535_360p_1301310230.mp4':
  
    Metadata:
  
      major_brand     : isom
  
      minor_version   : 1
  
      compatible_brands: isomavc1
  
      creation_time   : 2013-01-31 02:36:22
  
    Duration: 00:03:49.53, start: 0.000000, bitrate: 799 kb/s
  
      Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 699 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc
  
      Metadata:
  
        creation_time   : 2013-01-31 02:34:00
  
        handler_name    : GPAC ISO Video Handler
  
      Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 96000 Hz, stereo, s16, 95 kb/s
  
      Metadata:
  
        creation_time   : 2013-01-31 02:36:22
  
        handler_name    : GPAC ISO Audio Handler

  Media info results :

  General
  
  Complete name                            : a.mp4
  
  Format                                   : MPEG-4
  
  Format profile                           : Base Media
  
  Codec ID                                 : isom
  
  File size                                : 21.9 MiB
  
  Duration                                 : 3mn 49s
  
  Overall bit rate mode                    : Variable
  
  Overall bit rate                         : 799 Kbps
  
  Encoded date                             : UTC 2013-01-31 02:36:22
  
  Tagged date                              : UTC 2013-01-31 02:36:22
  
  
  
  Video
  
  ID                                       : 1
  
  Format                                   : AVC
  
  Format/Info                              : Advanced Video Codec
  
  Format profile                           : Baseline@L3.0
  
  Format settings, CABAC                   : No
  
  Format settings, ReFrames                : 3 frames
  
  Format settings, GOP                     : M=1, N=30
  
  Codec ID                                 : avc1
  
  Codec ID/Info                            : Advanced Video Coding
  
  Duration                                 : 3mn 49s
  
  Bit rate                                 : 700 Kbps
  
  Maximum bit rate                         : 2 721 Kbps
  
  Width                                    : 640 pixels
  
  Height                                   : 360 pixels
  
  Display aspect ratio                     : 16:9
  
  Frame rate mode                          : Constant
  
  Frame rate                               : 23.976 fps
  
  Color space                              : YUV
  
  Chroma subsampling                       : 4:2:0
  
  Bit depth                                : 8 bits
  
  Scan type                                : Progressive
  
  Bits/(Pixel*Frame)                       : 0.127
  
  Stream size                              : 19.1 MiB (88%)
  
  Writing library                          : Zencoder Video Encoding System
  
  Encoded date                             : UTC 2013-01-31 02:34:00
  
  Tagged date                              : UTC 2013-01-31 02:36:22
  
  
  
  Audio
  
  ID                                       : 2
  
  Format                                   : AAC
  
  Format/Info                              : Advanced Audio Codec
  
  Format profile                           : LC
  
  Codec ID                                 : 40
  
  Duration                                 : 3mn 49s
  
  Bit rate mode                            : Variable
  
  Bit rate                                 : 96.0 Kbps
  
  Maximum bit rate                         : 121 Kbps
  
  Channel(s)                               : 2 channels
  
  Channel positions                        : Front: L R
  
  Sampling rate                            : 96.0 KHz
  
  Compression mode                         : Lossy
  
  Stream size                              : 2.62 MiB (12%)
  
  Encoded date                             : UTC 2013-01-31 02:36:22
  
  Tagged date                              : UTC 2013-01-31 02:36:22

  I suspect the video player is more stricter on some codec header values. The level is set to 3.0 and this should be correct. Any help in figuring this out is appreciated !