Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sound.position() never reaches sound.length() #70

Open
francescosoave opened this issue Mar 5, 2018 · 11 comments
Open

sound.position() never reaches sound.length() #70

francescosoave opened this issue Mar 5, 2018 · 11 comments
Assignees
Labels
Milestone

Comments

@francescosoave
Copy link

francescosoave commented Mar 5, 2018

Hi, I'm not sure if this is a bug of if I missed something however I see that the sound.position() value never reaches the sound.length(). Is this normal or not? I'm using Processing 3.1.1

basically I was trying to do the following but the condition will never become true

if(sound.position() >= sound.length()){
        sound.pause();

for instance these are the final values I get if I run
println(sound.position() + " - " + (sound.length()))

7523 - 8072
7523 - 8072
7546 - 8072
7569 - 8072
7592 - 8072
7616 - 8072
7616 - 8072
7639 - 8072
7662 - 8072
7662 - 8072
7685 - 8072
7709 - 8072
7709 - 8072
7732 - 8072
7732 - 8072
7755 - 8072
7801 - 8072
7801 - 8072
7801 - 8072
7848 - 8072
7848 - 8072
7871 - 8072
7871 - 8072
7918 - 8072
7918 - 8072
7941 - 8072
7941 - 8072
7941 - 8072
7941 - 8072
7941 - 8072
7941 - 8072
7941 - 8072
@yonghuming
Copy link

have any solutions?

@francescosoave
Copy link
Author

not from me I'm afraid

@ddf
Copy link
Owner

ddf commented Feb 23, 2019

it should work, but might be file-specific. i realize i've taken a very long time to respond to this, but if you could provide me with an example problem file, that'd be great.

@ddf
Copy link
Owner

ddf commented Feb 23, 2019

It would also be helpful to know which class sound is in this case.

ddf added a commit that referenced this issue Feb 23, 2019
@francescosoave
Copy link
Author

Hello, thanks for the reply. I was using mp3 files. I can't attach them here but I'm happy to send them over in whatever way is good for you.

sound is just sound = minim.loadFile("/data/samples/sample1.mp3");

@ddf
Copy link
Owner

ddf commented Mar 2, 2019

If you could possibly share them via Dropbox or something similar, that'd be fantastic.

@francescosoave
Copy link
Author

link

in order to have it working I was doing something like

if(sound.position() >= sound.length()-200){ //do stuff }

@ddf
Copy link
Owner

ddf commented Mar 3, 2019

Thanks, I was able to reproduce the issue with these files and should be able to dig into it later today or tomorrow.

@ddf ddf self-assigned this Mar 3, 2019
@ddf ddf added this to the 2.3.0 milestone Mar 3, 2019
@ddf
Copy link
Owner

ddf commented Mar 4, 2019

Ok, after looking into this for a bit, I've determined that the problem is that the length() of the files is being misreported due to how it is determined by Minim. In all cases the length is longer than it should be. This means that when playing normally, the end of the file is reached before position() is equal to length().

Attempting to fix this properly is going to take a while, I think, due to the fact that Minim still contains a hacky workaround for how it deals with mp3 metadata. It may also turn out that it's unfixable (or require a patched version of mp3spi), since my attempt at a quick fix is essentially the same as what mp3spi does internally, which means it might be the case that the mp3spi library will also report an incorrect length() for these files. It's not clear to me yet whether or not this is a bug, however.

In the meantime, if all you are doing is calling play() and then want to poll for when the file finishes playing, it should suffice to check isPlaying(), which will switch to false when it reaches the end of the file. At least this is what happens with current code.

@ddf
Copy link
Owner

ddf commented Mar 4, 2019

Also, is it OK if I include the mp3 files you shared in this repo as part of a test case?

@francescosoave
Copy link
Author

hi, thanks for the reply. yes you can include 2 of them (I don't own the rights for the percussion track)

MLanghof pushed a commit to MLanghof/MP3ROR that referenced this issue May 1, 2019
- Cleaned up file loading.
- Added audio playback support (and worked around ddf/Minim#70).
- Parse and keep all physical frames of the song when loaded.
- Show current playback position in relation to byte position, physical frame number and song position in milliseconds (these were not completely trivial to align).
- Now showing a first crude visualization: Number of unused (empty) bytes per physical frame, plus a moving average of that. Some structure is evident there already.
- Switched to P2D renderer because the default one is awfully slow for a few thousand lines already. This somehow breaks key repetition (at least in Processing 3.3.6) >:(
- Stricter criterion for what is a header (not only "described frame is followed by 0xFF" but "there should be a valid header after the frame"). This may currently discard the last header if there is some non-frame data following it.
- Fixed CRC bit interpretation.
MLanghof added a commit to MLanghof/MP3ROR that referenced this issue May 4, 2019
- Cleaned up file loading.
- Added audio playback support (and worked around ddf/Minim#70).
- Parse and keep all physical frames of the song when loaded.
- Show current playback position in relation to byte position, physical frame number and song position in milliseconds (these were not completely trivial to align).
- Now showing a first crude visualization: Number of unused (empty) bytes per physical frame, plus a moving average of that. Some structure is evident there already.
- Switched to P2D renderer because the default one is awfully slow for a few thousand lines already. This somehow breaks key repetition (at least in Processing 3.3.6) >:(
- Stricter criterion for what is a header (not only "described frame is followed by 0xFF" but "there should be a valid header after the frame"). This may currently discard the last header if there is some non-frame data following it.
- Fixed CRC bit interpretation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants