Mark Nelson <markn <at> ieee.org> writes: > >But my question was if there is a receiver > >that plays the eac3 spdif file you uploaded: > > So the specific file that I posted here: > https://www.dropbox.com/s/tec7al5bcmihwey/sample.eac3.337.wav?dl=0 > > Works fine in my configuration, which is: File > playing in AJA Control Room, which generates an SDI > signal for ingest on a video encoder.
Does "playing" here mean you can hear the sound? > Similarly encoded files from the Dolby test kit in > both eac3 and ac3 formats work with AJA Control Room. Does "similarly" mean thy have the same "wrong" (see below) data-type as the file you uploaded? > I'm not sure what other tools Dolby targets for > files in this format. I use my amplifier to test and I consider that a very useful test. > (Similar files with AC3 content work fine also, and > I'm not entirely clear on what you mean when you > say this process can only work with eac3. But that's > a different issue.) It works for ac3, eac3, truehd and dts with my receiver. FFmpeg also supports MP3 and AAC but iirc, it is difficult to buy a receiver that supports them so I suspect this code is untested. > When I compare the Dolby WAV file to the > ffmpeg-created WAV file, by extracting the raw spdif: > > ffmpeg -i sample.eac3.337.wav -f s16le > -acodec pcm_s16le sample.eac3.spdif > > The payloads look fine, but I see a difference is in > the burst_info and length_code field of the SMPTE > 377M headers. > > header created by ffmpeg: 72 f8 1f 4e 15 00 00 03 > header stripped from dolby WAV file: 72 f8 1f 4e 10 00 00 18 I am looking at IEC 61937-2 and it specifies the following data-types in table 2: 16: ATRAC-X 21: Enhanced AC-3 So FFmpeg seems more correct to me;-) Btw, my receiver interprets "16" as TrueHD (which is 22). > The interesting thing here is that there is a > discrepancy in the location of the burst_info and > length_code data in these two files. One of them is > broken (I have a feeling I know which one you suspect.) > > The EAC3 frame in the ffmpeg created spdif file has a > length of 672 bytes, or 5376 bits, giving a length code > of 0x1500 Above table specifies "6 144" and this value has to be multiplied by 4 (afair) giving a frame size of 24576 which is what FFmpeg produces here for eac3 in spdif. This is the only frame size that works with my receiver for eac3. > The EAC3 frame in the spdif file extracted from the > dolby WAV file has a length of of 768 bytes, or > 6144 bytes, giving a length code of 0x1800 This is exactly one quarter of the required size and this simply doesn't work with the receivers I tested. > So the dolby file and the ffmpeg created file have > different endian layouts of just that section of > the SMPTE-377M the data. I did not see a difference in endianess: If I allow autodetection of "16" as eac3, your file can be decoded with FFmpeg. > Both have a reserved data type, but one is 0x03 > and one is 0x10. Maybe a newer version of IEC 61937 exists? > Maybe the problem here is that we are comparing > apples and oranges? S/PDIF vs. AES3? I don't know anything about AES3 but if it uses the same burst-preamble as spdif but different data-types then it is not the most useful format I ever saw;-) Did you test the file I produced with the commands I posted on your equipment? I still owe you a patch to disable spdif auto-detection (which is trivial) but I would also like to understand why your file is correct... Carl Eugen _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user