similar to: Something's driving me crazy

thank you Josh and Brian, I have tried to change the padding and I succeded in getting a same size file ... but still different :-( > ... different code paths through the encoder chosen at > runtime that are optimized for different environments which can > create different streams That said, I have to give up, there will be still cases in which I cannot get exactly the same FLAC file.

I'm attempting to decode part of a largefile flac whose seektable is broken or missing and the file is shorter then it's supposed to be, when I use 1.1.2 it decodes fine, when I use 1.1.3 it fails flac --decode --skip=719:58.0 --until=1024:58.0 -o \/home\/sbh\/work\/hs\/out.wav \/mnt\/ss\/sdb\/Sound\/Recording\/2006\-11\-29\/in.flac out.wav: ERROR seeking while skipping bytes

I'm attempting to decode part of a largefile flac whose seektable is broken or missing and the file is shorter then it's supposed to be, when I use 1.1.2 it decodes fine, when I use 1.1.3 it fails flac --decode --skip=719:58.0 --until=1024:58.0 -o \/home\/sbh\/work\/hs\/out.wav \/mnt\/ss\/sdb\/Sound\/Recording\/2006\-11\-29\/in.flac out.wav: ERROR seeking while skipping bytes

I've checked in code that supports a new metadata block called SEEKTABLE. Basically, it is an optional, arbitrarily-long list of seek points, by sample number and stream offset. I also added command-line options to flac so you can specify seek points by specific sample number and/or a specific number of evenly-spaced seek points. The table cost about 18 bytes per seek point. This seems to

Hi! I've been using a little C++ program I've written to encode flac files. The program does this in the usual way (I think), by inheriting a class from FLAC::Encoder::File, and passing it chunks of raw samples through process_interleaved()... Anyway, the program works beautifully, and I've now decided to try and add some metadata to the encoded flacs. Eventually, there will be vorbis

Hello, I'm using flac to compress s signal data during capture. The sample rate is almost a thousands time higher compared to audio (40 MHz), resulting in a lot of data very quickly. I'm using the C API in my capturing application (mostly copy&paste directly from the example) and it works so far, but unfortunately for longer captures there is no seeking information. How can I tell

As far as I can tell I've found a serious bug in the command line flac encoder :( I have created many hundreds of flac files and I was very annoyed to discover that the XMMS flac plug-in had intolerably long seek times, but since that had been mentioned on this list a bunch of times without anyone actually investigating, I thought I had better actually find the BUG which causes this. 1. I

Op zo 13 okt 2024 om 02:16 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > I cannot find any clues in the documentation how to write a > seektable/reserve space for it. > Can someone help me out? > There's actually quite a lot of documentation for this. Please review https://xiph.org/flac/api/group__flac__stream__encoder.html#ga80d57f9069e354cbf1a15a3e3ad9ca78

Hi Martijn, Am 13.10.24 um 21:00 schrieb Martijn van Beurden: > > There's actually quite a lot of documentation for this. > > Please review https://xiph.org/flac/api/group__flac__stream__encoder.html#ga80d57f9069e354cbf1a15a3e3ad9ca78 > > I quote: >> SEEKTABLE blocks are handled specially. Since you will not know the >> values for the seek point stream offsets,

(I am not on this list, please CC me manually if necessary) On Fri, Mar 15, 2002 at 11:47:15PM -0500, Asheesh Laroia wrote: > Are you sure it's not your compiler? That's the first thing I would > check. I know that RedHat is famous for including broken pre-releases of > GCC in their distributions since 7.0. FUD. Please stop that, it makes you look unprofessional. Until you can

Please excuse me, I haven't yet dug into the code too far. What I'd like to do: I'm using ecasound to record for 24 hour periods, which pipes the output directly to flac. I would like to be able to decode sections of this (using until/skip) during recording/encoding. I understand currently that flac can't do this, unless I pipe into dd to skip after decoding (which would be an

The attached patch adds the missing FLAC__metadata_object_seektable_*() functions from FLAC's metadata object methods (FLAC/metadata.h) to FLAC++'s SeekTable class. Of the 11 functions in the C API, only 4 are currently in the C++ API, this patch adds the missing 7. If this patch is ok, VorbisComment will be next. A quick look tells me only 5 out of 13

On 12/11/06, Josh Coalson <xflac@yahoo.com> wrote: > --- Avuton Olrich <avuton@gmail.com> wrote: > > I'm attempting to decode part of a largefile flac whose seektable is > > broken or missing and the file is shorter then it's supposed to be, > > when I use 1.1.2 it decodes fine, when I use 1.1.3 it fails > > > > flac --decode --skip=719:58.0

I have read FLAC's "--help", the man-page, and the HTML documentaion, but there are a few things that I don't understand. 1. I'll start with the thing I'm most confused about. The --best option is synonymous with -l 12 -b 4608 -m -e -r 6. Why is that? Is not -l 32 better that l- 12? And you can have -r 0,8 without using --lax, and -r 0,16 with --lax. 2. The --lax option

OK, I'm sure this has been mentioned before but I'm really struggling now! The problem is best described here: https://bugs.freedesktop.org/show_bug.cgi?id=9456 I've added my own Mandriva cooker bug here: http://qa.mandriva.com/show_bug.cgi?id=27971 People also make reference to the issue here: http://forum.go-compiz.org/viewtopic.php?t=309&view=next Has anyone got any ideas?

Hallo, *<:-) may be I'm to tired to see the solution, maybe someone can give me a hint? I do have a couple of servers, sending the daily logwatch report to a central support email account. Some servers do have DNS A and CNAME records. On my mailserver relaying for the servers is allowed. Only one server drives me crazy, getting user unknown or releaying denied messages. Any idea, how

Op zo 13 okt 2024 om 22:33 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > Is the seektable written at the beginning of the file in the metadata > block or can there also be a second metadata block at the end? > Only at the start of the file. > > If it's at the beginning, would it possible to reserve space for N seek > points and during encoding remember

Op di 15 okt 2024 om 21:27 schreef Alistair Buxton <a.j.buxton at gmail.com>: > > I would like to see this kind of thing put into a secondary metadata block aimed specifically at SDR. This could be completely ignored by regular audio players - these files are not meant to be listened to anyway. I could probably figure out how to implement that, I even started looking into it once, but

I found that for a modern PC running zero loads, (my server is a P4 3.2 with 512 M dual channel RAM an Intel Etherpro Express 100 nic, serving cached disk files from RAM) samba could be 30% slower than it should be. It would serve data at about 7 MBytes/sec compared with the old NT4 sever (same Intel nic, 512 RAM, P2/266 Cpu, NT4 with SP6a) that would do it at 10 Mbytes/sec under all

hi guys i have CentOS-5.1 with samba-3.0.25b-0.el5.4 and i took this workin well smb.conf from slackware12 ( commands to be done befor this ): # useradd wbc -c /home/wbc -g users# smbpasswd -a wbc# mkdir /export# chmod u+rwx,g+rx,o+rx /export# chown wbc.users /export the conf file:[global]workgroup = WORKGROUPnetbios name = sanshirosecurity = share [share]comment = Datapath = /exportforce user