Comments (6)
As an alternative to #60, I just created #65, which partly implements option 2 from above.
It doesn't check for forbidden arguments, though (they are just silently ignored).
Both have their shortcomings, but I still slightly prefer option 3 (with its implementation in #60).
from python-soundfile.
So, to summarize, our options are:
- Keep everything the way it is. This conflates
'r+'
with'x+'
, depending on whether the file exists or not. This could theoretically be disambiguated with a manual check, but at any rate, this leaves the nomenclature in an unpleasant place that is neither pythonic nor sndfile-like. - Go with straight sndfile nomenclature (#65). The main disadvantage is that
'rw'
conflates'r+'
and'x+'
in an occasionally unpleasant way. On the other hand, the implementation is somewhat simpler. - Try to be as pythonic as possible (#60). This will probably open every file in virtual-IO mode and the implementation will be a bit more complicated. The upside is that we can support most of the open modes of
open
. A related simplification would unify the read- and write-pointer (though this might prove problematic for non-seekable file types).
I see this mainly as a trade-off between interface pythonicity and implementation simplicity.
Personally, it took me quite a while to wrap my head around the intricacies of the separated read/write pointers and the different truncation behavior of libsndfile's modes (as apparent from our discussions here). For this reason, I am slightly in favor of 3. PySoundFile is better for being less surprising and more pythonic. However, we should be vigilant about the implementation complexity--if 3 proves to have too many unforeseen consequences and require too many unforeseen workarounds, we should probably back down and go with 2.
Is there anything important I missed? What do you think?
from python-soundfile.
Is there anything important I missed?
No, that's about it.
I just want to add that the complexity is currently not that much worse in #60 than in #65.
OTOH, the error handling is much cleaner in #60.
We'll have to deal with the non-seekable problem anyway, #67 has to be fixed no matter what we decide here.
The problem may get worse though, because in #60 additional seek()
calls are introduced.
And the solution will probably add more complexity to #60.
I guess we should first check how we can solve the non-seekable problem in #60 and then we can decide if #60 or #65 (or something else) is the best choice.
from python-soundfile.
I added checks for the seek()
calls in #60 (046023c).
It was only a minor thing, the complexity wasn't increased significantly.
I still prefer #60 over #65, because the slightly larger complexity buys much clearer semantics and much better error handling.
I think it's also much better than the current state.
I vote for merging #60!
What do you think?
from python-soundfile.
I agree!
from python-soundfile.
I merged #60 and closed #65, therefore I'm also closing this issue.
from python-soundfile.
Related Issues (20)
- Value Error: array is too big when loading .flac file
- soundfile crashes when trying to export long .ogg file HOT 1
- soundfile.LibsndfileError: Error opening <_io.BytesIO object at 0x0000022B81C21850>: Format not recognised. HOT 2
- Cannot suppress warnings when decoding mp3
- Cannot open Ogg FLAC file: unknown error in flac decoder HOT 1
- miniforge3/lib/python3.9/site-packages/soundfile.py", line 1229, in _init_virtual_io def vio_get_filelen(user_data): MemoryError: Cannot allocate write+execute memory for ffi.callback(). You might be running on a system that prevents this. For more information, see https://cffi.readthedocs.io/en/latest/using.html#callbacks
- Cannot write Ogg files over 96 seconds long at 44.1 kHz HOT 4
- soundfile.info does not work on mp3 HOT 2
- soundfile.LibsndfileError: <exception str() failed> HOT 6
- How to save left and right channel in separate files? HOT 1
- soundfile.LibsndfileError: Error : unknown error in flac decoder. HOT 2
- "Format not recognised." for m4a files HOT 2
- soundfile.LibsndfileError: Error opening <tempfile._TemporaryFileWrapper object at 0x7feadae59070>: Format not recognised. HOT 2
- Part of mp3 is loaded. HOT 2
- unknown error in flac decoder HOT 2
- Capture libmpg123/libsndfile warnings HOT 1
- 24-bit data not written/read properly HOT 4
- REQUEST: Allow resampling when loading non-raw files HOT 1
- New release with updated libsndfile binaries HOT 1
- Cannot read mp3 with file-like object HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-soundfile.