Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Identify LPCM audio media info

Help
sam bul
2012-06-03
2012-12-11
  • sam bul
    sam bul
    2012-06-03

    Can MediaInfo be fixed to decipher media info from multichannel LPCM encoded audio files like .l16 or .l24? I was trying MediaInfo and Gspot - no result. Why is that, and what program can ID media data in such files, like codec used, number of channels, depth, frequency, etc.

     
  • I have no idea of what is .l16 .l24 formats, please provide example files and open a feature request ticket:
    https://sourceforge.net/tracker/?group_id=86862&atid=581184
    If your file have absolutely no header indicating number of channels / depth / frequency (if the file contains only raw PCM samples), as I can imagine with the file extension, there is no possiblity to know such data and only the creation tool can know such information (from somewhere else?)
    If your ifle has an header, do you have an idea of the format name (an extension is not enough)?

     
  • sam bul
    sam bul
    2012-06-03

    Thanks. This audio format is used as standard in Audio CDs and DVDs. My files were transcoded to LPCM from 5.1 Flac with **eac3to** using its LibFlac.dll. I can upload samples, or you can transcode any multichannel Flac to LPCM with eac3to using command:

    eac3to input.flac output.lpcm

    Resulting file can be streamed to network players, some understand extension .l16, and some .lpcm too.

    You can find more about LPCM in this** Wiki article and this** Mpeg standard. It has no header whatsoever. Nonetheless, I believe FFMpeg -i command can decipher media info from some of such files by analyzing hex data, despite it was not encoded with ffmpeg.

    LPCM format is the uncompressed lossless audio mandatory to support under DLNA spec for media streaming devices. It usually doesn't contain any header, unless packed in WAV, AIFF or another container. It would be highly desirable, if you can implement empiric analysis algorithm to decipher media info from file hex code.

     
  • sam bul
    sam bul
    2012-06-03

    I created a ticket and uploaded file, but don't see that ticket shown up. Not sure, may be 6Mb file was too big or it took too long to upload it. More info on LPCM is in this Media Wiki article. Audacity can import such RAW files and shows partially correct deciphered media info before importing them.

     
  • Resulting file can be streamed to network players, some understand extension .l16, and some .lpcm too.

    Do they understand the file if file extension is different? How can they know the sampling rate from the file extension + raw stream only (44, 48, 96 KHz)? You provide no info on your side?

    You can find more about LPCM in this Wiki article and this Mpeg standard

    In the case of DVDs, there is an header. MediaInfo already supports such PCM stream detection.

    FFMpeg -i command can decipher media info from some of such files by analyzing hex data

    Tested with eac3to success.wav output.lpcm (file from eac3to package, the resulting lpcm is the same file without WAV header) then ffmpeg -i, no detection.

    It usually doesn't contain any header, unless packed in WAV, AIFF or another container

    I support such PCM streams (or in AVI, MPEG-4…)

    LPCM format is the uncompressed lossless audio mandatory to support under DLNA spec for media streaming devices.

    as raw PCM? I have difficulties do believe it. Or in a container (MPEG-2, or MPEG-4)?

    It would be highly desirable, if you can implement empiric analysis algorithm to decipher media info from file hex code.

    It is completely different work to detect such stream with empirical analysis rather than reading an header. Additionaly, it is really really rare to have to deal with raw PCM. So I don't plan to add such "file format", at least with free support. And for paid support, it would be very very expensive, I think.

    I created a ticket

    Weird, I don't see it.

    More info on LPCM is in this Media Wiki article

    I know all of your links ;-).
    But it does not resolve the issue of the raw stream. All your links speak about PCM in a container (WAV, MPEG-2, MPEG-4/MOV…)

    Audacity can import such RAW files and shows partially correct deciphered media info before importing them.

    And YOU must provide the channel count, the sampling rate, the byte order, the bit depth… Audacity does not detect them. Because it is impossible to detect them, IMHO.
    Maybe bit depth / byte order / channel count is possible with lot of audio integrity tests, but for sampling rate, I can not imagine how to differentiate 44 KHz from 48 Khz data…

     
  • sam bul
    sam bul
    2012-06-03

    Thanks. This Samsung player **spec** (a typical one) shows it supports LPCM (raw PCM) playback. I can confirm, my player easily plays raw PCM from eac3to without any container whatsoever with extensions .l16 and .l24 only. I think, extension recognition is limitation of DLNA standard, but everything else is done by the player (well .l16 means 16-bit by default).

    However, it can play only 2-channel LCPM via DLNA protocol, not multichannel - it plays slow. 2-channel LPCM limit in DLNA is discussed **here** among other streaming sites. Since DLNA is defacto standard for billions of devices on the market, and LPCM is lowest denominator audio format they all must support at least in 2-channel, MediaInfo IMHO should be updated to include such files info recognition.

    It might be a challenging task, but if every DLNA device does that (no container required), there must be common algorithms available and working very reliably. :)

     
  • my player easily plays raw PCM

    I still wonder how it can detect 44 kHz vs 48 kHz… And what happens if you provide a 96 kHz file? What happens if you provide a mono-channel file?
    Because I don't like such sentence from your links " (It will play 48K files, but with distortion). " -> Absolutely no sampling rate detection is made. It is expected to be 44 kHz for this player, but another player can expect 48 kHz.

    The specifciations seem to be hard coded, and if you are not in the specifications, no file reject, only weird behavior. For MediaInfo, it is not acceptable: I try to provide information for (pretty) sure, or I don't provide it.

    but if every DLNA device does that (no container required),

    From your links, it seems to be: DLNA player expect a very specific format, and if it is not the case they have weird behavior. Not a good algorithm ;-).

    Anyway, it is not a planned feature for me (the main developer). A patch may be accepted if it is reliable.

     
  • sam bul
    sam bul
    2012-06-03

    You're probably correct in your observations. Some new Apps are coming that will allow Samsung player to play media without DLNA 2-channel restrictions. Not sure if it will affect "hard coded" specs in its firmware, but its also continuously updated. Anyway, just wanted to point your attention that an extremely large pull of devices exists out there that use LPCM files your MediaInfo tool can't identify at all. And the number of such devices is growing exponentially as we speak: all smart phones, BD and Media players, new TVs, etc. :)

     
  • sam bul
    sam bul
    2012-06-04

    Actually, its likely that audio/L16 format as a subset of LPCM format is locked by standard to a set of default parameters like 44100/16/2, so all media devices need to do is check the file extension. I tested this assumption, and the same file plays OK when media parameters match the above set AND extension is .l16. If extension is different, the file isn't visible via DLNA interface. If I save a file with different media specs under .l16, it still plays but garbled. Hence, the player doesn't seem to check media info apart from file extension (at least for LPCM file types).

    This might make your work easier, limiting it to finding the proper standard, and MediaInfo giving info like this:

    "The files with that extension by default have the following standard specifications…"  It seems better than nothing. :)

     
  • Testing the file extension is not acceptable. One of the requests from lot of other users is especially not to depend of the file extension. Additionally, I don't always have it (people can use MediaInfo with named pipes, memory buffers…).
    Additionaly, testing the extension is something not difficult for a tool ;-).
    Summary: this solution is not acceptable inside MediaInfo. Won't fix, because it is not fixable (relying on the file extension is not a solution)

     
  • sam bul
    sam bul
    2012-06-05

    I agree that testing file extension is not a reliable solution. However, testing LPCM files is not "my requirement", I just pointed your attention to this broad problem, which exists on its own (without me) with large segment of popular consumer devices complying with DLNA standard. And LPCM playback is the only way to listen lossless audio from such devices.

    But most MedaInfo  users would disagree that a generic solution to find at least some media info from LPCM files is impossible. The hex code pattern itself can tell a lot when combined with other empirical methods. You might not be interested (or able) to develop such solution, but to say that solution impossible is incorrect.

    Thanks for your helpful tool! Sorry, I can't help to resolve the issue other than draw attention to it.

     
  • sam bul
    sam bul
    2012-06-08

    " 2012-06-03 08:34:49 PDT

    I have no idea of what is .l16 .l24 formats"

    The problem seems to be, MediaInfo tool was long oriented towards A/V formats playable via traditional means, i.e. from a laser disk on hardware player, or a media file on PC software player. But current overwhelming trend supported by broad and fast growing range of modern devices is Media Streaming. And it relies upon streamable over net A/V formats that were not covered by the set of traditional A/V standards.

    I found some relevant standards that may help you in modernizing your tool to current requirement. I know you may claim that its perfect and doesn't need any modernization, and there is no demand for new A/V formats whatsoever. Unfortunately, from a typical iPhone or Streaming Media & BD & TV Player owner standpoint it may no longer be true.

    In particular, some useful info can be found in  RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control and RFC 2586 The Audio/L16 MIME content type. Both standards seems to be actively used by streaming DLNA compliant devices.

     
  • In particular, some useful info can be found in  RFC 3551 RTP Profile for Audio and Video Conferences with Minimal Control and RFC 2586 The Audio/L16 MIME content type. Both standards seems to be actively used by streaming DLNA compliant devices.

    For RTP: Exact, MediaInfo currently does not support RTP.
    For HTTP (RFC 2586); Exact, MediaInfo currently does not support HTTP MIME type.
    But none of theses formats is the thing you requested at the beginning, it is completely different.

    MediaInfo tool was long oriented towards A/V formats playable via traditional means,

    I don't agree "only by traditional means".
    - A .l16 file only on the disk is not what you are speaking about now with your links. A file extension is known not to be trustable. I don't want to rely only on file extension (again, it is a request from my users not to trust file extensions). Additionaly, the file extension is something easy for anyone to test, no need of MediaInfo. It is completely different than a "container" used to transport the stream. If you really want something so basic than file extension test, I could add an option to MediaInfo to accept only the file extension as "magic" value, but due to the very few people interested in such test, it will be professional service (more work to do on implementing the option than the test itself!). If you are ready to sponsor such option, it is possible, ask for a quotation. But do not expect this option to be set by default.
    - I support what my users wants me to support. The "containers" RTP and HTTP are currently not really requested by me users (as far as I know). Adding RTP or HTTP to the list of "containers" I can analyze is not "new means vs traditional means", it is only another "container", nothing was invented there. But (nearly) nobody is interested in theses "containers".

    Conclusion:
    - testing only the file extension is currently rejected (in free support, to be precise). Not trustable enough + easy for anyone to test without MediaInfo.
    - testing the RTP header or HTTP header is possible. Add a feature request. But I prefer to warn now: it is not a priority for me currently (feature not sponsored).

    For your information, HTTP(S), (S)FTP(E)(S), MMS(H) are already (not officially) supported "containers", but not by default (library compilation option currently, I did not have the time to test all, the code was developped for specific need from one of my customers, and the GUI is not ready). But currently for HTTP, the MIME type (in the HTTP header) is discarded (support of HTTP MIME type is possible, but not implemented).

    By the way, something funny: did you read the RFC 2586? default sample rate is NOT 44 KHz. It is 8 KHz. You said your file is 44 KHz. so… Can you provide the official specification for files having ".l16" extension? It is definitely not the same as RFC 2586 ;-).

     
  • sam bul
    sam bul
    2012-06-09

    Lets clarify something: I'm not here to criticize your tool, but to suggest how it can be updated to reflect current media usage trends. And, I can't unfortunately sponsor its development at the moment. But, your tool is great and has being very useful for many people for a long time. Though in the next few years up to 60-80% of media playback will move to streaming, so you're behind the trend, and it shows.

    As to this particular example of .l16 format, currently choosen by DLNA Guidelines for lossless playback, pls review RFC 3551 again:

    Section 4.5 Audio Encodings:

    Table 1: Properties of Audio Encodings

    L16       sample        16               var.                   20

    Table 4: Payload types (PT) for audio encodings

    10   L16         A           44,100       2
    11   L16         A           44,100       1

    And if you look how the hex is coded for different formats right in this standard, and contact its maintainers for advice, you can engineer a more generic algorithm able to ID not only .l16 (which is quite limiting), but also ANY streamed LPCM media content. And possibly look at other mentioned formats from that standard, because smaller devices & smart phones tend to use them instead.

     
  • Again, now you speak of RTP. RTP is not a file on the disk, it is not related to a .l16 extension, it is different. You can add a feature request to support RTP, and all stream formats supported by RTP wil be detected. RFC 3551 is not about PCM, it is about RTP (with PCM, QCELP, GSM, MPEG Audio… transported formats, for the RFC you pointed. Other RFC includes H264 and other audio/video formats)

    Read again the RFC, you can read that there is a clock and so on, so you can have for sure the sampling rate, the channel count… It is not the case of a .l16 on your hard drive.

    So: what do you want?
    - .l16 on the disk? optional option to rely on the extension, never by default because extension is not reliable. You still did NOT provide a specification for this format (RTP or HTTP RFC are absolutely not a specification for a file on the disk). Provide a specification to prove there is an acceptance this file extension is reserved to "44 KHz 2-channel PCM" (for example) (DLNA specs?)
    - HTTP or RTP support? It is possible
    None of theses features will be done on free support due to the low interest (you are maybe interested, but not a lot of people are), I can accept patchs.

    And possibly look at other mentioned formats from that standard, because smaller devices & smart phones tend to use them instead.

    Again, there is absolutely nothing new: I already support all of theses stream formats when they are in other containers (MPEG-4, 3GPP, MPEG-TS, AVI…), if you want the support of another container, no problem, nothing new, MediaInfo is ready to receive new code built to support theses "containers".