Help needed from MPEG audio experts

Discussion in 'Amateur Video Production' started by Gary, Sep 2, 2003.

  1. Gary

    Gary Guest

    I bought this little handheld multi-track recorder called the Korg
    PXR-4. It encodes audio to SmartMedia using MPEG-1 layer 2 or MP2.
    The MP2 files it creates load just fine into audio apps like Sound
    Forge. Unfortunately, if you attempt to transfer a file that
    originated elsewhere and was converted to MP2, or one that originated
    on the PXR-4 but was edited, it often will crash the unit with a
    DSP:0015 error (not that I expect anyone outside of the Korg design
    team to know what this really means).

    To attempt to see what will make the unit crash I've recorded a number
    of test files with sweeps at various levels, noise, speech, etc.
    Oddly most of these work fine, but when I take an actual music track
    say from SONAR, and covert it to the proper MP2 format, it will still
    crash the unit within 15 seconds.

    I got a copy of the ISO document that describes MP1, MP2, and MP3 and
    have written a program that will scan an MP2 file and read the headers
    (which is not very exciting, but easily enough done). I don't believe
    the compatibility has anything to do with the original or copyright
    bits because I've tried various permutations of that and it seems not
    to matter.

    I'm guessing that the h/w encoder in this unit is only able to do a
    subset of what a full-fledged encoder really needs to do, but since
    they've balanced it out with a matching decoder it doesn't matter so
    long as you stay on the unit.

    My question to you experts - what could it possibly be?
     
    Gary, Sep 2, 2003
    #1
    1. Advertisements

  2. SCMS? Don't know, but some material from other sources may have such a bit
    turned on while the original files from the Korg don't. There are too many
    possibilities. Perhaps import into another application as a test? If you
    check the headers there should always be a SCMS bit available, but if Korg
    doesn't implement it, perhaps the header gives the program the wrong
    information from where that bit would normally reside on. Certainly that
    should make an application go "what the ****?". At least with the
    information you've provided it seems like a possibility, however unlikely.

    --


    Roger W. Norman
    SirMusic Studio
    Purchase your copy of the Fifth of RAP CD set at www.recaudiopro.net.
    See how far $20 really goes.
     
    Roger W. Norman, Sep 2, 2003
    #2
    1. Advertisements

  3. Gary

    nappy Guest

    What this probalby means is that the DSP decoder failed due to the units
    inability to correctly parse ANY MP2 or MP3 file format. While writing an
    MP3 class for a well known MI company I discovered that there are many
    little gotchas when trying to accomodate MPx files from different sources.
    Proper parsing of the file would fix that .. It appears the DSP section of
    the decoder is getting a bad block start because of incorrect parsing of the
    data MP3 headers. If it starts on bad data then anything can happen from
    there on in.

    nappy
     
    nappy, Sep 2, 2003
    #3
  4. That's interesting, though this program I wrote does decode the headers and
    will let you know if something's out of order. I've noticed a couple
    possible weird things -

    #1 the sync bits FFFD showing up in the audio data area?
    #2 the ASCII characters 'KORG' at the end of certain audio blocks in some
    files (probably those supplied by Korg).

    By "proper parsing" I assume you mean re-ordering the input somehow? As
    far as I can tell all MP2 files are byte-aligned even though it is defined
    as a bit stream and to be 100% accurate you'd need to do bit shift and
    compare instead of byte compare.

    The other thing I thought is that some of the scale factors may not be
    allowed. Does that make any sense? I.e. I'm thinking of something
    analogous to a A/D-D/A pair with matching missing codes.
     
    Digital Larry, Sep 3, 2003
    #4
  5. Gary

    nappy Guest

    The algo I wrote dealt with VBR and standard headers and data. It is
    possible for those data to show up elsewhere which is why I had to use the
    frame size as an important part of determining the next available real
    frame. Getting around non audio data in the beginning of the file is also
    somewhat tricky. ;



    Perhaps that is what they write in filler data.


    no.. just dealing with every incarnation of that particular MPx class. And
    failing without crashing when other file types are encountered. I wrote code
    that read the file type and determined if it was an unsupported type...
    which sometimes meant determnining exactly what type it was. Whether our
    engine played that type or not.


    As
    If you are working with bits, flags or any other partial data, ye you do
    have to do bit fiddling.



    You would have to be able to make test files and test that theory.. I am not
    sure about decoding scale factors. I did not have to go through that
    torture! I was using the Windows codec.

    best
     
    nappy, Sep 3, 2003
    #5
  6. Gary

    Samuel Paik Guest

    What he probably means is that there is a lot of bad software out
    there, which takes major shortcuts when decoding a file/bitstream which
    work when used with a specific bit of kit, but don't work in general.

    Another example of this is digital cameras--many digital cameras can
    only display images produced by itself, and won't display images produced
    by other hardware/software. They don't really parse the files completely,
    instead they assume the file has headers in particular locations in the
    file, etc.

    Sam
     
    Samuel Paik, Sep 3, 2003
    #6
  7. Gary

    Gary Guest

    Fortunately MP2 does not support VBR - the frame size is fixed at 144
    * bit rate/sample rate. Also the ISO document includes rather
    explicit pseudo-code for reading the bit stream - though I haven't
    gotten that far yet.
    Oddly, there is a provision in MP2 for "ancillary data" between the
    end of the audio block and the next sync bits.... but this 'KORG'
    stuff appears to be right in the audio granule data, usually after a
    stream of zeros. It does not appear in every block and it also
    doesn't seem to be a prerequisite for compatibility. There are a
    bunch of MP2 drum loops on the Korg Japan web site and none of those
    appear to have 'KORG' embedded... but they all work, leading me to
    believe that Korg wrote an MP2 encoder that behaves the same way as
    the hw implementation in the PXR-4.
    Once again I think the MP2 situation is vastly simpler than MP3, at
    least what I can gather from the ISO document.

    Thanks for your comments!
     
    Gary, Sep 3, 2003
    #7
  8. Gary

    Gary Guest

    I see what you mean, my Olympus camera cannot take back its own files
    that have been edited. However the MP2 data format is very
    straightforward. There's a private bit, copyright, original, a few
    others, but any significant variations beyond that appear to jump
    right into the heart of the decoder algorithm. That is to say, I
    have been looking for these types of differences between files that
    work and ones that don't, and have not found them. To get into the
    decoder is a significantly more involved programming effort and I also
    don't know the exact significance of the data that I'm looking at.
    Allocation bits, scale factors, granules, etc. I did study DSP about
    25 years ago but this stuff was not the rage back then.
     
    Gary, Sep 5, 2003
    #8
  9. Gary

    Warren Young Guest

    Have you tried different encoders? One in particular you might look at
    is tooLAME, the MP2 companion to the LAME MP3 encoder. It is more
    configurable than most encoders; you may be able to make it spit out a
    file the Korg box will like.

    Since this is a perceptual encoding format, no two encoders will produce
    the exact same file. This is why the ISO docs talk about the files in
    terms of what a player should do when it sees certain data, rather than
    "how to encode".

    Another thing you might try, if you have access to a Linux or Unix box,
    is to build LAME from source so that you get their graphical analyzer
    tool which reads in MP3 files and dissects them. Since MP2 is a proper
    subset of MP3, this may prove illuminating.
    Highly likley.
     
    Warren Young, Sep 9, 2003
    #9
  10. Gary

    Andrew M. Guest

    I thought that MP3 is a subset of MPEG1 (MPEG 1 layer 3 is how I have
    seen it). Is MPEG 1 a "proper" subset of MPEG 2?
     
    Andrew M., Sep 9, 2003
    #10
  11. Gary

    Samuel Paik Guest

    MPEG Layer 3 is subsection of the MPEG audio part.
    MPEG video is not a subset of MPEG 2 video, but close. MPEG-2
    changed the chroma subsampling point, for one.

    I can't say I'm at all familiar with the audio part though.
     
    Samuel Paik, Sep 9, 2003
    #11
  12. What I've decided to do (though with 4 month old twins it may take awhile)
    is to use the Freeamp GNU source that includes MP2 decoder code from Xing
    apparently, and shove the good/bad streams through it and develop
    histograms of the scale factors and other components, since I suspect that
    there are certain codes that will never show up from the Korg encoder.

    Of course, assuming I identify those things, what to do about it becomes
    the next dilemma. No doubt forcing the value arbitrarily to an accepted
    one will create some artifact. I just don't want to have to decode/re-
    encode, not so much for quality reasons as that is a hell of a lot of work
    to do for no pay.
     
    Digital Larry, Sep 11, 2003
    #12
  13. Hmmm, that is very interesting. With tooLAME you can select one of four
    perceptual models. It's worth a try. Thanks! Once again I think the
    answer will be that the Korg decoder (and encoder of course) is missing
    some algorithmic pieces and crashes when it encounters them, such as the
    scale factor selection index I think it's called, where we decide which
    frames will be used to decode the current audio packet.
     
    Digital Larry, Sep 11, 2003
    #13
  14. Gary

    Warren Young Guest

    "MP3" is MPEG-1 audio layer 3.

    The audio "layers" are different levels of complexity in the audio
    encoding part of the MPEG-1 standard. Layer 1 is the simplest, but no
    one uses it, since layers 2 and 3 fill people's needs better. Layer 2
    is what we're talking about in this thread. It's used in DVDs and other
    areas where the extra bandwidth required by MP2 isn't a big enough deal
    to make it worth paying the MP3 royalties.

    The layers are backwards compatible. An MP3 decoder is supposed to
    decode MP2 and MP1 streams, and an MP2 decoder is supposed to also be
    able to decode MP1 streams.
    MPEG-2 decoders are supposed to understand all valid MPEG-1 streams,
    both audio and video. It may be as Samuel says, in that an MPEG-2
    encoder would encode the video differently than an MPEG-1 encoder (all
    else being equal), but when an MPEG-2 _decoder_ is given an MPEG-1
    stream, it is expected to decode it properly.
     
    Warren Young, Sep 12, 2003
    #14
  15. Gary

    Gary Guest

    Fer any of you following this white-knuckle drama, I have an
    interesting update. I did get the DOS version of tooLAME.exe to do
    WAV to MP2 encoding. Using psy models 0, 1, and 2 (only ones I tried
    so far) I was able to get a six minute track easily over to the Korg
    recorder to use as a guide track. No DSP or Card errors. I will also
    say that I really could not tell the difference between the different
    psy models - perhaps going at 192 kbps helps reduce artifacts.

    The evidence so far is empirical - all I can say is that several WAV
    files encoded by tooLAME work fine where they did not work fine when
    encoded by other algorithms (the BWF codec and the one built into
    dbPoweramp). This is great news to me and opens up the PXR-4 to
    vastly expanded horizons - since I don't have to come up with the
    I often start with rhythm track developed in SONAR then flesh it out
    with guitar parts - this is exactly what I had in mind when I bought
    the PXR-4.
     
    Gary, Sep 15, 2003
    #15
  16. Gary

    Samuel Paik Guest

    I'm not sure it is a requirement that an MPEG-2 decoder must be able
    to handle MPEG, but my copy of the ISO MPEG-2 specifications are filed
    in a not very convenient location for checking just for a Usenet post
    (it's in one of the boxes that I haven't unpacked since my last move)
    I think it would be foolish for an MPEG-2 decoding system not to
    support MPEG however.

    Sam
     
    Samuel Paik, Sep 16, 2003
    #16
  17. Gary

    Nutz Guest

    Have you tried loading it into CoolEdit (AKA Adobe Audition) and
    regenerating it?
     
    Nutz, Sep 16, 2003
    #17
  18. Gary

    Gary Guest

    The best solution I've found was to encode to MP2 from WAV using
    open-source encoder tooLAME. It's a command line program but since
    source is available I can incorporate it into my own Windows program
    that does a few other things for this specific situation.

    I still don't understand why this encoder works where the other ones
    don't, but if it continues to work OK I don't really care why.
     
    Gary, Sep 16, 2003
    #18
  19. Gary

    Warren Young Guest

    I only have the Systems section, so I can't check, either.

    It says in the Haskell et. al book, "...all Simple, Main, SNR, Spatial
    and High profile conformant [MPEG-2] decoders shall be able to decode
    all constrained parameters conformant bitstreams of MPEG-1 video." The
    langauge of that statement reads like a priest paraphrasing the Bible:
    very careful to preserve the source material's meaning while not quoting
    directly.

    It isn't quite as strong a statement as what I said, but it's probably
    the same thing in practice.
     
    Warren Young, Sep 16, 2003
    #19
  20. Gary

    Samuel Paik Guest

    Ah, yes, that's pretty strong. I think it says that if you claim to
    be conformant to an MPEG-2 profile, you must also be able to decode
    MPEG-1 video whose constraints fall within the same constraints of
    that MPEG-2 profile.

    Sam
     
    Samuel Paik, Sep 17, 2003
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.