From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS6130 216.105.38.0/24 X-Spam-Status: No, score=-2.0 required=3.0 tests=BAYES_00,BODY_8BITS, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id B27F11F8C8 for ; Thu, 7 Oct 2021 12:23:14 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1mYSQU-00050O-F8; Thu, 07 Oct 2021 12:23:06 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYSQS-0004zu-9X for sox-devel@lists.sourceforge.net; Thu, 07 Oct 2021 12:23:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=MIME-Version:Content-Type:Subject:References: In-Reply-To:Message-ID:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WvIdO1jv8DIYbm4HsW2Hr1klKli5PLwsaWIIoLM77WA=; b=FA5SSZSj/zj0kwhgWc8k8F+Cl IfJ9Unb7VT0bexFcRVs+Bhl6pkHetbZ4/heL04HGxYG1QppudZi0vspkdsGQzDo8w02GAOvutGSDF uF+Jr7EYcsSKW+Wm+Z9Q3WNbTcu+14DsaJEKuZ9UHxakseRxHv7Hbc+K8K5KOwvWTMSZk=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=MIME-Version:Content-Type:Subject:References:In-Reply-To:Message-ID:To: From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WvIdO1jv8DIYbm4HsW2Hr1klKli5PLwsaWIIoLM77WA=; b=hD1CsJJIDG16vyem6W74wBPBBm jpH1k/vTb6vTrkWM6bQS6VhZkgFaOmQ1dQLdNUKL5xbpQTFMUGimLAOKgrchdbJKkAHLiMeY94kTS LrAsf0UhwZ4UlkJetDA0UrgDom8k6T/+2UvCYappQqDdecWw+aLjqOzKi0jXM0vbY2Fg=; Received: from mail-os2jpn01olkn0147.outbound.protection.outlook.com ([104.47.92.147] helo=JPN01-OS2-obe.outbound.protection.outlook.com) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) id 1mYSQN-0005MV-V4 for sox-devel@lists.sourceforge.net; Thu, 07 Oct 2021 12:23:04 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FWYVpvppm/jHRyGrSk3ul7A512SIzPEInAZpmmO7gIszWOCkNlC/zpqsYgdtqJVX9f7c0LCgV5KvwoQxMEpUgpiMfIfkwbqUgAXKBseUtRDdTVpLLQFz+oarOivN2gG2rVJhfxuoM2dAfTSY5z7rJHmgMQCrMCKz0GwWwsxP45jFku78NL6dLwNU+x0ASWvXrkEnni1sljgDGw5n6r6PeKJ+zp90D0TQRfIzjgBK6wIbuDiUMiJrQo6OXZ04F8CBit7YYZw8N1H9BPM0u2Vk0q430OE+Wr6hRoV0waCxL8teR+GZlC/1fA8WWxjbmJdH59ZBzAmP35qB9XfrozDr4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=WvIdO1jv8DIYbm4HsW2Hr1klKli5PLwsaWIIoLM77WA=; b=Z3PHKGGu9xgiWCdjBLuuzw1pDg5Ao9xYolGhxOpxrKNFRT2h/9sUv9BJY+fDLyk931HjAwRPn9p6x5IcU6YhkpRUmtfoOCpDIOOaQGkU9uZw+CDlUVJhdHlWqG8Q4QXpU/DPu50a4o0vY3FBubqnw59WcVYPA073OGVL9w7oXouowd5vqH06h8t9GsFSgwxHtOS4bzgSQxNRlcWVYDVrcnAIaZ0rsTZfPOW9L016cbSej3X3A7Ph617PqlOXlYHcno4SdceQyrWdo/Df85lZ34s1Ylgr2lqeEc+mCZ2GQpJHKZ8BxO7EFVsYUJhdHQr37pm23FGGhKM5iR20EiF+Dw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WvIdO1jv8DIYbm4HsW2Hr1klKli5PLwsaWIIoLM77WA=; b=UIl1ZkFIEyKIRq6WfLkbOKNFnhhFVxmOS5nXVTqMA6zlaMGh09ixjJuPa/TA7fL+PhxXjuFQFLLHLK2gnKt5A9ANNRgsCkYFnrPO561igvlG1RmPGvcNa3PiwDlscZ0JOMCTRg8vbyJLPEKgnBq9q8vrEs8PUORKTGUTRjYcG0J0Gn7/p1bvRUR1vL8uELtGWn5mSMDMXG++XS2lxz2vdFJ99GLN98Y/kUhsowmkf3IIBIBYwL+bthy91VJ2aMEIoxqCaf/NxwTdXBQQNp6ZttBm6BmF87dNIH+y/EyZ/+Bgt9zV5H27rcU1fMC6Kv5QNe5E7uZEy3ypDwLKi3JS/w== Received: from OS3PR01MB5976.jpnprd01.prod.outlook.com (2603:1096:604:d8::13) by OSBPR01MB1927.jpnprd01.prod.outlook.com (2603:1096:603:1f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Thu, 7 Oct 2021 12:22:51 +0000 Received: from OS3PR01MB5976.jpnprd01.prod.outlook.com ([fe80::e14f:40a0:5df6:f6c6]) by OS3PR01MB5976.jpnprd01.prod.outlook.com ([fe80::e14f:40a0:5df6:f6c6%8]) with mapi id 15.20.4587.018; Thu, 7 Oct 2021 12:22:51 +0000 Date: Thu, 7 Oct 2021 20:22:36 +0800 From: Sun Zhenliang To: sox-devel@lists.sourceforge.net Message-ID: In-Reply-To: References: X-Readdle-Message-ID: b255634f-d569-4875-b4ff-8b1dab7b0cf3@Spark X-TMN: [dt8cadnTagyzzusGwrWKSueqhzHL4uTIbDLu1gjsippqt32LRQafmNqJq9Frn/Vl] X-ClientProxiedBy: HK2P15301CA0019.APCP153.PROD.OUTLOOK.COM (2603:1096:202:1::29) To OS3PR01MB5976.jpnprd01.prod.outlook.com (2603:1096:604:d8::13) X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [240e:39a:348:59c1:100::] (240e:39a:348:59c1:e101:f3cc:441c:5341) by HK2P15301CA0019.APCP153.PROD.OUTLOOK.COM (2603:1096:202:1::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.1 via Frontend Transport; Thu, 7 Oct 2021 12:22:48 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dfb6ac99-5715-465c-962d-08d9898d2e22 X-MS-TrafficTypeDiagnostic: OSBPR01MB1927: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: thL8QLRBGvfvnH7exqhA//aQvO3zEhctBdasuDl88IuEjWnnoICthpH5+wEcggYEWdh/bjm+A+2GMu9WLBwx7ZY+128cubA8rh/g+JUF03bvyZ+i+pI/Y//HKb0cpwUBUL+rD1MyNO7cBe+mm0Had45I+VK9gxeiWnXLAMUF649CcQkK/EsveyzxCxYTATldWRSy6n7CLD7cCS0Is710wpPQyG70OkK3xuHfZgx7xdZKfxAt4o/Q8sbSi/xEDDfJE0WbYUthnZwRs/V+4evsPHM8RDcoheYi3fx8LFmw8FiOXSppZR1+k9K334+mPSZSthn8LNAx7aA8vqYafN1uESMuQXZM0Z7MaZ8tKBJVcNclK7q/RVkNmMjNlH5I4ki//oyWzLw582sZDrFubpFyoEy7LL8AdKp4sOcY7UOwkpJTzO7U9x182wuyjjPAZy2m9t4aM2fDFwG3LJARLllfWhvze6cUs16fpbA+/PHPlM4CKjRrU8dktFIsjxkzX9dzTEWP8v2JD05KUNeF+dE3Hg== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: BwKAWvWIPSk+ESzRTU9+k2//KjzSA91XzR5XRLURJ0ZicTFrvlFOvQ6YN1P+0twsWp59Ck5rZvA64edbWWkZNt2Ne4ScKBcHv7VlyFLaLMj5K8vWDh7F6ihSwsAldCRybfgBY/9tUPHLwhA3Df7puLi8CzseLjzfXTQdvgL03RcoBEEzCtvqL7rAD85BWtI6kPNo5au1XRYrrMh8OtmT/A== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfb6ac99-5715-465c-962d-08d9898d2e22 X-MS-Exchange-CrossTenant-AuthSource: OS3PR01MB5976.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Oct 2021 12:22:51.1578 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB1927 X-Headers-End: 1mYSQN-0005MV-V4 Subject: Re: .Re: [PATCH] formats: disallow seeking in dynamic memory buffers X-BeenThere: sox-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sox-devel@lists.sourceforge.net Content-Type: multipart/mixed; boundary="===============7990812421142113953==" Errors-To: sox-devel-bounces@lists.sourceforge.net --===============7990812421142113953== Content-Type: multipart/alternative; boundary="615ee692_109cf92e_230f" --615ee692_109cf92e_230f Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =E5=9C=A8 2021=E5=B9=B410=E6=9C=887=E6=97=A5 +0800 14:18=EF=BC=8CSven Neu= mann via SoX-devel =EF=BC=8C=E5=86=99=E9= =81=93=EF=BC=9A > Hi, > > thanks for pointing me to=C2=A0https://sourceforge.net/p/sox/mailman/me= ssage/37325794/. This is exactly the problem I am trying to solve. > > I am=C2=A0somewhat surprised that we can actually recover the whole buf= fer after a seek and write because the memory stream maintains a null byt= e after the data. I was assuming that this means that we can not simply r= ecover by seeking back to the end of the buffer because one byte would ha= ve been overwritten by that terminator byte. I tried what you suggested (= code attached), and it seems that the terminating null byte is not moved = on a seek operation, but only when the file descriptor is closed. > > Of course it would be desirable to have a proper WAV header even for st= reams opened with sox=5Fopen=5Fmemstream=5Fwrite(). I can prepare a fix t= hat introduces a seek back, but I guess I would have to do something simi= lar for all formats that seek in the output buffer. Before I start to wor= k on that I would like to get approval from the maintainer that this is t= he right approach. Yes, I guess there are lots of works to do related to this seek opt.=C2=A0= =C2=A0Let me know if you need any help. Regards, SunZhenliang > > > Regards, > Sven > > > =46rom: Sun Zhenliang > Sent: 07 October 2021 04:24 > To: sox-devel=40lists.sourceforge.net > Subject: Re: =5BSoX-devel=5D =5BPATCH=5D formats: disallow seeking in d= ynamic memory buffers > > =E5=9C=A8 2021=E5=B9=B410=E6=9C=887=E6=97=A5 +0800 05:35=EF=BC=8CSven N= eumann via SoX-devel =EF=BC=8C=E5=86=99= =E9=81=93=EF=BC=9A > Hi, > > in one of our internal applications we are using SoX (the 14.4.2+git201= 90427 version from Ubuntu) to convert from a variety of audio formats to = the WAV file format. We observed that the tests for the conversion occasi= onally failed and over the last days I found time to dig deeper into this= . > > We are using sox=5Fopen=5Fmemstream=5Fwrite() to write to a dynamically= allocated in-memory stream. In our tests sometimes the size of the resul= ting WAV buffer would have the expected size, sometimes it would be 44 by= tes, the size of the WAV header. Valgrind told me that the behavior of is= =5Fseekable() in formats.c depends on uninitialized memory. In your git r= epository I found a fix for this: > > commit bb38934e11035c8fab141f70dabda3afdd17da36 > Author: Mans Rullgard > Date: Tue Aug 4 17:19:49 2020 +0100 > > format: improve is=5Fseekable() test > > Streams opened with fmemopen() do not have an underlying file descripto= r, > so the fstat() will fail, and a random result is returned. > > A simpler method that works regardless of file type is to call fseek() > and check if it reports success. > > Suggested by Stefan Sauer . > > > Now with this fix applied valgrind was happy, however now our conversio= n from MP3 to WAV would always result in only 44 bytes, as read from the = buffer=5Fsize=5Fptr location passed to sox=5Fopen=5Fmemstream=5Fwrite(). = It turns out that with above change the undefined behavior is fixed for s= treams created with open=5Fmemstream() and is=5Fseekable() will now relia= bly returns sox=5Ftrue for such streams. This allows the WAV writer code = to do an fseek() to the start of the stream followed by a write of the WA= V header with correct length information. However such a seek followed by= a write causes the dynamically allocated memory stream to be truncated. = Thus after calling sox=5Fclose() the size reported for the stream will be= 44 bytes, that's not what we want. Unfortunately we can not simply fix t= his by reporting the full buffer size as the buffer will actually have be= en truncated, and a trailing null byte is appended after the WAV header. = It looks like we can indeed not seek and fix data in a dynamically alloca= ted stream. Thus I am attaching a patch that changes the code in formats.= c to set ft->seekable to false for streams opened with open=5Fmemstream()= . With this change applied on top of the improvement for the is=5Fseekabl= e() test, our tests pass reliably and valgrind seems happy as well. > > I am attaching the patch here, please consider it for inclusion. I am a= lso attaching a simple test application that writes to a stream, seeks to= the front and performs another write. The output of this program illustr= ates that the buffer is truncated: > > buf =3D =60hello', size =3D 5 > buf =3D =60hello, world', size =3D 12 > buf =3D =60heyho', size =3D 5 > Bug mentioned=C2=A0https://sourceforge.net/p/sox/mailman/message/373257= 94/. > > It is possible to fix the whole data. =46rom my test to open=5Fmemstrea= m(), the > dynamically allocated memory would not be free before the ft->fp was cl= osed. > The data written is still there if it=E2=80=99s not covered by other wr= ite opt. > > In this WAV issue, the seek opt is just in sox=5Fclose() to rewrite hea= der, which > is the end of transcoding and will not cover the data area. We can just= ftell() > to get the end of file before the fseek and seek back to the end after = rewriting. > > Output with ftell opt: > buf =3D =60hello', size =3D 5 > buf =3D =60hello, world', size =3D 12 > buf =3D =60heyho, world', size =3D 12 > > As for other formats, the situation may be different from WAV and needs= specific > analysis. > > > > Regards, > Sven > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > SoX-devel mailing list > SoX-devel=40lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sox-devel > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > SoX-devel mailing list > SoX-devel=40lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sox-devel --615ee692_109cf92e_230f Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
=E5=9C=A8 2021=E5=B9=B410=E6=9C=887=E6=97=A5 +0800 14:18= =EF=BC=8CSven Neumann via SoX-devel <sox-devel@lists.sourceforge.net>= =EF=BC=8C=E5=86=99=E9=81=93=EF=BC=9A
Hi,
thanks for pointing me to https://sourceforge.net/p/sox/mailman/messag= e/37325794/. This is exactly the problem I am trying to solve.

I am somewhat surprised that we can actually recover the whole buffer = after a seek and write because the memory stream maintains a null byte afte= r the data. I was assuming that this means that we can not simply recover b= y seeking back to the end of the buffer because one byte would have been ov= erwritten by that terminator byte. I tried what you suggested (code attache= d), and it seems that the terminating null byte is not moved on a seek oper= ation, but only when the file descriptor is closed.

Of course it would be desirable to have a proper WAV header even for stream= s opened with sox_open_memstream_write(). I can prepare a fix that introduc= es a seek back, but I guess I would have to do something similar for all fo= rmats that seek in the output buffer. Before I start to work on that I woul= d like to get approval from the maintainer that this is the right approach.=
Yes, I guess there are lots of works to do related to thi= s seek opt.  Let me know if you need any help. 

Regards,
SunZhenliang


Regards,
Sven


From: Sun Zhenliang <hisunzhenliang@outlook.com>
Sent: 07 October 2021 04:24
To: sox-devel@lists.sourceforge.net <sox-devel@lists.sourceforge.net>=
Subject: Re: [SoX-devel] [PATCH] formats: disallow seeking in dynamic memor= y buffers
 
=E5=9C=A8 2021=E5=B9=B410=E6=9C=887=E6=97=A5 +0800 05:35=EF=BC=8CSven Neuma= nn via SoX-devel <sox-devel@lists.sourceforge.net>=EF=BC=8C=E5=86=99= =E9=81=93=EF=BC=9A
Hi,

in one of our internal applications we are using SoX (the 14.4.2+git2019042= 7 version from Ubuntu) to convert from a variety of audio formats to the WA= V file format. We observed that the tests for the conversion occasionally f= ailed and over the last days I found time to dig deeper into this.

We are using sox_open_memstream_write() to write to a dynamically allocated= in-memory stream. In our tests sometimes the size of the resulting WAV buf= fer would have the expected size, sometimes it would be 44 bytes, the size = of the WAV header. Valgrind told me that the behavior of is_seekable() in f= ormats.c depends on uninitialized memory. In your git repository I found a = fix for this:

commit bb38934e11035c8fab141f70dabda3afdd17da36
Author: Mans Rullgard <mans@mansr.com>
Date: Tue Aug 4 17:19:49 2020 +0100

format: improve is_seekable() test

Streams opened with fmemopen() do not have an underlying file descriptor, so the fstat() will fail, and a random result is returned.

A simpler method that works regardless of file type is to call fseek()
and check if it reports success.

Suggested by Stefan Sauer <ensonic@google.com>.


Now with this fix applied valgrind was happy, however now our conversion fr= om MP3 to WAV would always result in only 44 bytes, as read from the buffer= _size_ptr location passed to sox_open_memstream_write(). It turns out that = with above change the undefined behavior is fixed for streams created with = open_memstream() and is_seekable() will now reliably returns sox_true for s= uch streams. This allows the WAV writer code to do an fseek() to the start = of the stream followed by a write of the WAV header with correct length inf= ormation. However such a seek followed by a write causes the dynamically al= located memory stream to be truncated. Thus after calling sox_close() the s= ize reported for the stream will be 44 bytes, that's not what we want. Unfo= rtunately we can not simply fix this by reporting the full buffer size as t= he buffer will actually have been truncated, and a trailing null byte is ap= pended after the WAV header. It looks like we can indeed not seek and fix d= ata in a dynamically allocated stream. Thus I am attaching a patch that cha= nges the code in formats.c to set ft->seekable to false for streams open= ed with open_memstream(). With this change applied on top of the improvemen= t for the is_seekable() test, our tests pass reliably and valgrind seems ha= ppy as well.

I am attaching the patch here, please consider it for inclusion. I am also = attaching a simple test application that writes to a stream, seeks to the f= ront and performs another write. The output of this program illustrates tha= t the buffer is truncated:

buf =3D `hello', size =3D 5
buf =3D `hello, world', size =3D 12
buf =3D `heyho', size =3D 5
Bug mentioned https://sourceforge.net/p/sox/mailman/message/37325794/.=

It is possible to fix the whole data. From my test to open_memstream(), the=  
dynamically allocated memory would not be free before the ft->fp was clo= sed. 
The data written is still there if it=E2=80=99s not covered by other write = opt. 

In this WAV issue, the seek opt is just in sox_close() to rewrite header, w= hich 
is the end of transcoding and will not cover the data area. We can just fte= ll() 
to get the end of file before the fseek and seek back to the end after rewr= iting.

Output with ftell opt:
buf =3D `hello', size =3D 5
buf =3D `hello, world', size =3D 12
buf =3D `heyho, world', size =3D 12

As for other formats, the situation may be different from WAV and needs spe= cific 
analysis.



Regards,
Sven




_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel

_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel
--615ee692_109cf92e_230f-- --===============7990812421142113953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============7990812421142113953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel --===============7990812421142113953==--