similar to: Supporting real-time UTC timestamp data

Hi there, for a streaming application developed for a project at the Society for Arts and Technology Montreal, Canada, we would need to know the exact delay of our ogg/vorbis streams. It seems there are several factors that make up the total delay I get. Is there a way to find out how large the delay introduced by the encoder and decoder is? Or in other words, how many unprocessed samples

Hi Justin, I have a suggestion, but it may not be very convenient. You could try converting the 24/96 BWF to AIFF, and then use flac to compress the 24/96 AIFF. There is no difference in audio quality between the FLAC file generated from BWF (WAV) vs. AIFF, so perhaps this extra step will solve your problem in the short term. Sorry I haven't used BWF or WAV very frequently, but

Hi everyone, I'm working on a WebM plug-in for Premiere. You probably already know that WebM is a Matroska container that uses Vorbis for audio compression. I'm pretty new to the world of audio compression and need some help. You can see my code here: http://github.com/fnordware/AdobeWebM First of all, I wonder if it's possible to seek to an exact audio sample in WebM. Whereas

David Jagu (1): meson: fix typo in libdrm_intel Geert Uytterhoeven (18): util: improve SMPTE color LUT accuracy util: factor out and optimize C8 SMPTE color LUT util: add support for DRM_FORMAT_C[124] util: store number of colors for indexed formats util: add SMPTE pattern support for C4 format util: add SMPTE pattern support for C1 format util: add

On 7/16/15, Martin Leese <martin.leese at stanfordalumni.org> wrote: > Martijn van Beurden wrote: >> I would propose: 0000-0111 : (number of independent channels)-1. >> The channel order is defined through the >> WAVEFORMATEXTENSIBLE_CHANNEL_MASK vorbis comment, if defined. If >> no WAVEFORMATEXTENSIBLE_CHANNEL_MASK is present, the channel >> order follows

On 13-07-22 11:19 AM, Brendan Bolles wrote: > Hey everyone, according to Wikipedia's 4-year-old information, there is no standard for putting metadata into an Ogg file. That metadata must be included in the codec. That's correct in that there's no container-level metadata. The 'mapping' specs for various sets of codecs embedded in Ogg describe how metadata is stored. >

Matthew, I don't think I can answer your entire question, but I will list a few pieces of information. 1) I regularly convert very large AIFF files, up to 4 GB, using flac. I sometimes work with WAV, and that seems to work, too. On my Mac, I can play flac files just fine in Play.app, VLC, and my own software. 2) What do you mean the flac "files do not work"? You mean

There is some time now that I reported this issue on the bugtracker: https://roundup.ffmpeg.org/roundup/ffmpeg/issue1325 And this guy, jbr, kindly created a patch that solved the problem. What is needed now for the patch to be included in the SVN? About his patch, there is a remap table that maps the channel order from SMPTE order to Vorbis order. What is this SMPTE order? Vorbis specification

Came across another error that might help! Using flac -t I get: 251_A.wav: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC 251_A.wav: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC Thanks, Matthew On Feb 6, 2008 3:19 AM, Matthew Davis <zasdarq@gmail.com> wrote: > Thank you for the reply! I know that my system can play flac files, I've >

lvqcl wrote: ... > From FLAC 1.2.1 documentation: > > 0000-0111 : (number of independent channels)-1. Where defined, the channel > order follows SMPTE/ITU-R recommendations. The assignments are as follows: > 1 channel: mono > 2 channels: left, right > 3 channels: left, right, center > 4 channels: left, right, back left, back right > 5 channels: left, right, center,

[Going a bit off-topic here, and going to do a bit of a deep-dive on RF stuff, but maybe it will be useful to Chris] On 05/24/2017 12:20 PM, Valeri Galtsev wrote: > It is insightful, yet... There are a bunch of other factors that may need > to be taken into account. Angular transmission pattern of satellite (horn? > or is it yagi? antenna) vs ground based (monopole? or dipole? antenna -

lvqcl wrote: > Martin Leese wrote: >> Note that the channel order may not be defined. > > IMHO it doesn't matter in this place of documentation (which describes > default channel assignments for FLAC). Your proposed wording was: 0000-0111 : (number of independent channels)-1. The channel order follows SMPTE/ITU-R recommendations. The assignments are as follows: The

--- Justin Waddell <jwaddell@gmail.com> wrote: > I have exactly the same problem. > > I encoded a BWF file to flac and then then decoded back to wav, using > --keep-foreign-metadata, and I ended up with a bit-perfect copy of > the original BWF. So I was fairly confident that the flac encoding is > working correctly, the problem definitely appears to be with the flac >

I have exactly the same problem. I encoded a BWF file to flac and then then decoded back to wav, using --keep-foreign-metadata, and I ended up with a bit-perfect copy of the original BWF. So I was fairly confident that the flac encoding is working correctly, the problem definitely appears to be with the flac players. Unfortunately it seems that the majority of flac players cannot play 24bit

Brendan Bolles wrote: > Hey everyone, according to Wikipedia's 4-year-old information, there is no > standard for putting metadata into an Ogg file. True. > That metadata must be > included in the codec. More generally, in a stream in the Ogg file. Codecs are streams, but so are things like Ogg Skeleton. Information about Metadata has been collected together in the Xiph Wiki

Thank you for the reply! I know that my system can play flac files, I've played others I've managed to convert using both of those programs. I'm only running into difficulty when it comes to these large WAV files. By "Does not work" I mean that they do not play, and instead I receive the errors I mentioned in my original post. I wasn't actually intending to use

Martin Leese wrote: > Your proposed wording was: > 0000-0111 : (number of independent channels)-1. The channel order > follows SMPTE/ITU-R recommendations. The assignments are as follows: > > The channel order might not follow SMPTE/ITU-R > recommendations, so this proposed wording > seems misleading to me. But this text describes only those 4 bits in frame header. IMHO

And more info... Screen capture of the WAV file's hex. This tells me little, but maybe someone out there knows more about this than me. http://img139.imageshack.us/my.php?image=screenshot251awavghexnd1.png Thanks again, Matthew On Feb 6, 2008 12:18 PM, Matthew Davis <zasdarq@gmail.com> wrote: > Came across another error that might help! Using flac -t I get: > > 251_A.wav:

Hi, I am attempting to use flac to encode 96k/24-bit broadcast wav (BWF) files. BWFs are wav files with some extra meta-data chunks, and is the favoured archival format for many institutions around the world. These files are encoded successfully by flac, however the resulting flac file is not playable on all flac players - it plays successfully in foobar2000 but is silent in winamp, and when

On Thu, Dec 16, 2010 at 12:29:58PM -0800, Bryan D. Brown wrote: > I'm having a major problem with the timestamps in both the Icecast access.log and error.log. The timestamp on the logfiles themselves is accurate, but the logging of the various connections to my streams is in UTC. No matter how I try to configure the hwclock or the system clock, the log timestamp is always UTC, which is 8